harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Wed, 24 Jan 2007 15:59:16 GMT
On 1/24/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> On 1/23/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > On 1/23/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > >
> > >
> > > Based on my prior experience with M2N frame work, I have the same
> > > feeling that compiler instrinsic might be able to deal with fast
> > > native call (except some corner cases where very special calling
> > > convention ect. is used, e.g., the native method itself is a
> > > hand-written asm code sequence.)
> > >
> > > Probably the compiler instrinsic semantics can be expressed with Java
> > > Magics, then they are just the same thing from different viewpoints.
> > >
> > >
> > The problem is with usual JNI calls. JIT knows nothing about M2N frames
> > today. Pavel wants to encode JNI stub's body with magics and do not add
> any
> > knowledge about M2N into JIT.
> Yes, I see his point. I wonder what is the main benefit. Is it to save
> the two "call" instructions?

Inlining help us not only avoid 'calls' but also give a chance to propagate
parent method data into inlined methods. Sometimes even 1 extra call
elimination is worth to do. For example, removal of call for monenter helper
gave ~5x speedup on microtests.

> So we have 2 new magics: allocateMemChunkOnStack(size) and
> > saveRegisters(Address, howToSave)
> > The problem left is EIP handling. Before making direct call JIT pushes
> > call's args, saves caller-save regs, so EIP changes.
> > When unwinding native call VM uses EIP saved in M2N frame. JIT can't
> find
> > call by this EIP and this is the problem.
> > I'll take a break here for a day to think more about it and read others
> > ideas how to deal with EIP...
> >
> Go with the compiler intrinsic approach, JIT doesn't have to compile
> the stub code blindly as common magics. It knows the stub is for fast
> native call, then it can intelligently emit code to handle EIP.
> Annotation or pre-generated asm sequence may help.
> Well, we need judge if it's worth doing with the complications.

Intrinsic approach has one drawback: there can be a lot of info in M2N frame
that JIT does not want to know.
With help of magics we can try to split M2N stub into 2 parts:
1) Custom part: here VM developer can link M2N into the list, save method
handle, check for exceptions, do anything else VM need.
2) General part: this the intrinsic you mentioned. JIT must save registers
into the specified area and generate a call.

In the case 2) we can use the approach proposed by Pavel above and add the
method like:

callNative(Address nativeAddr, Address m2nRegSaveAddr, Params..)
where m2nRegSaveAddr points to the area allocated on a stack

Another problem is how to pass params (number of params? types?). Any ideas?

Xiao-Feng, did I miss something from your proposal about intrinsics?

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message