On 1/22/07, Pavel Afremov <[EMAIL PROTECTED]> wrote:
See my comments inline please. On 1/22/07, Mikhail Fursov <[EMAIL PROTECTED]> 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 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.
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. Problems: 1) IR inlining allows copy propagation and optimizations across inlined method. ASM stub inlined as a sequence of native commands does not allow optimizations. 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.
ok 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
