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