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 Mon, 22 Jan 2007 18:03:47 GMT
On 1/22/07, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> See my comments inline please.
> On 1/22/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> >
> > Pavel,
> > I see the direction of your improvement - optimization of JNI calls.
> > The scenario you proposed is  (correct me if I'm wrong)
> It's more close to "Replace LiL code by Magic".

Note that today a helper written with magics works only after its class is
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.

> Problems:
> > P1) GC in native code -> we need to iterate stack. In this case VM
> > restores
> > registers from M2N frame. So JIT must store registers using the same
> > layout
> > as VM restores them. This is a new contract between VM and JIT. Do you
> > have
> > any proposals how to implement this contract and do not pass any
> knowledge
> > about VM internals to JIT?
> My proposal is reuse m2n_gen_push_m2n and m2n_gen_pop_m2n (see
> …./vm/port/src/lil/ia32/pim/ m2n_ia32.cpp line 195, 270 ). These
> functions  generate
> required code using CodeGenarator. I think that JIT should inline this
> code
> in compiled code instead call of put_registers(Adress m2nFrame).

Do I understand correctly that your proposal is to support inlining of ASM
stubs? This is quite a big and performance questionable task.
1) IR inlining allows copy propagation and optimizations across inlined
ASM stub inlined as a sequence of native commands does not allow
2) If ASM stub uses registers, we need to support something like
CallingConvention for stubs..

My proposal: Lets add the method:
put_registers(Address addr, Calling_Convention cc)
'cc' is a contant that determines registers and order.

P2) M2N frames are linked into a list. Is it right that helper's code is
> > responsible to support the list?
> Linkage in the list should be written on the java (Magic) code, as store
> of
> frame_type, method handle and etc.


P3) What JIT must save to EIP register?
> Any value which can provide frame unwinding and exception handling in
> generated code. So unwind_stack_frame and method lookup find() should
> works
> with stored eip value successfully. I think "mov eip_value, EIP" will be
> OK.

put_registers is not the same operation as native method call. So you can
write a sequence like
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?

P4) How to protect native call's args if GC happens in native code?
> Like any other args in other calls. We can reuse JNI mechanism here for
> example. Could You provide more details, in what problem is?

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.

Mikhail Fursov

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