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 Tue, 23 Jan 2007 15:26:40 GMT
I see two "looks and feel" for fast native call: What is more suitable for
JIT?



   1. Like JNI (see example). This case is easy to use in usual helpers



@FastCall
public void native fastNativeMethod(args...);

…

fastNativeMethod(args);



   1. Call by address like in example. This case is more flexible and
   will be very usefull for fast invocation api



static final Address FAST_NATIVE_METHOD = GetMethodAddress1();

Adress theOthreFastNativeMethod = GetMethodAddress2();

…

fastNativeCallByAddr(FAST_NATIVE_METHOD, args);

fastNativeCallByAddr(theOthreFastNativeMethod, args);



Thanks

Pavel Afremov


On 1/23/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
>
>
>
> On 1/22/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> >
> > Note that today a helper written with magics works only after its class
> > is
> > initialized.
> > It means that before "magic" class is initialized VM uses old, slow
> > version
> > of the helper.
> > So you can't replace LIL with magics today. But I agree that we should
> > remove LIL and replace it with direct encoder's calls.
>
>
>
> Agree. We can't remove Lil code totally now, but we can start the process…
>
>
>
> > My proposal: Lets add the method:
> > put_registers(Address addr, Calling_Convention cc)
> > 'cc' is a contant that determines registers and order.
>
>
>
> I agree. Could you describe, suitable for you Calling_Convention structure
> more closely.
>
>
>
> > put_registers is not the same operation as native method call. So you
> > can
> > write a sequence like
>
>
>
> I understand it.
>
>
>
> > 1) put_registers(mn2) -> save EIP
> > 2) something else
> > 3) do fast native call
> > Is this sequence OK? Could VM gurus who wrote stack unwinding code in VM
> >
> > help us here?
>
>
>
> I wrote many parts of  stack unwinding code in VM ;),   and  your  code
> sequence is OK for me, except point 2), between 1 and 3 shouldn't be done
> anything else..So right sequence is:
>
> 1) do something  else.
>
> 2) put registers
>
> 3) call native method.
>
>
>
> So if "find" function of JIT can find method and code chunk info by this
> IP, unwind_stack_frame can provide frame unwinding by this IP and
> get_root_set_from_stack_frame will be able to enumerate stack than it means
> that IP will be OK.
>
>
>
> > Will your helper contain the  code to protect native method args?
> > The problem is that  if GC happens in  native method, VM but not JIT is
> > responsible to report native method args as part of rootset.
>
>
>
> Native code will protect useful args values. So if JITed code transfers
> pointer to ManagedObject via stack for example, native code doesn't miss
> this value during garbage collection. But it doesn't mean warranty that
> value on the stack will be updated, and JITed code can't use it in future.
>
> Thanks
> Pavel Afremov.
>
>
>
> > --
> > Mikhail Fursov
> >
> >
>

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