harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Thu, 25 Jan 2007 07:42:02 GMT
Yes, this two parts solution probably is necessary. We don't need to
be purists to constrain ourselves.

Thanks,
xiaofeng

On 1/24/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> 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?
> Pavel?
>
>
>
> Xiao-Feng, did I miss something from your proposal about intrinsics?
>
>
>
> --
> Mikhail Fursov
>
>

Mime
View raw message