On 1/22/07, Mikhail Fursov <[EMAIL PROTECTED]> 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
