harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Afremov" <pavel.n.afre...@gmail.com>
Subject Re: [drlvm][magic] New Magic features proposal.
Date Thu, 25 Jan 2007 10:37:30 GMT
Hello



I thing the following proposal can be useful.

Class org.vmmagic.unboxed.JNICall and org.vmmagic.unboxed.NativeFastCall should
be added.

Magic code writer should extends them in his internal clases, and declare in
these internal clssses native methods which can be called from magic code.

It shold be looks like in example:

...

class MagicHelper {

    …

    class MyJNICalls extends JNICall {

        public static void native jniMethod1(Address, Address, Address
/*jniEnv*/, Object /*objectThis*/);

    }



    class MyNativeFastCalls extends JNICall {

        public static Object native nfcMethod1(Address, Address);

        public static Object native nfcMethod2(Address, Address, String
/*description*/);

        public static void native nfcMethod3(Address, Address, int
/*counter*, Object /*lock*/);

    }



    void myMagicHalper() {

        int lockCounter = 0;

        Object lockObject = MyNativeFastCalls.nfcMethod2(nfcMethod2Addr,
m2nRegSaveAddr, "My Lock Object");



        MyJNICalls.jniMethod1(jniMethod1Addr, m2nRegSaveAddr, jniEnv,
lockObject);

        MyNativeFastCalls.nfcMethod3(nfcMethod3Addr, m2nRegSaveAddr,
lockCounter, lockObject);

    }

}

…

The other possible way use annotation instead  MyJNICalls andMyNativeFastCalls
classes.


Thanks.
Pavel.


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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message