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 Mon, 22 Jan 2007 12:03:06 GMT
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".


> 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).

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.

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?



Thanks.

Pavel Afremov.

--
> Mikhail Fursov
>
>

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