On 10/13/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Why is this a problem, am I misunderstanding? Even with conventional helpers, the jit needs to know the helper method signatures. We don't need to worry about universality of GC's. Any compatible GC will need to implement exactly the same helper fastpath contract interface as Xiao Feng says elsewhere.
Yes. The only amendment from me is that JIT does not want to know if GC is compatible or not. For example some GC developers may try to implement bump pointer allocation by decrementing the offset in a block (like a stack) or to do some cleaning like Ivan did. But I'm agree with you that our GCv4.1 and GC_GEN could use the same fast-path helper. I asked this question because of MMTk collectors. It has slightly different format of the allocation sequence. If you look into the WB helpers you see that the difference is even more than allocation one. IIRC the MMTk WB helper needs 4 params to be reported from JIT while our GC_GEN only 2. So we have to support in JIT different versions of the same helper.
I don't think that the jit needs to know that an object being finalizable implies not to invoke the fastpath. This to me suggests that the jit determines allocation policy. I don't see a problem passing the object typeinfo or allocation handle to the helper. It is needed for object init anyway.
Doing isFinalizable check during a compile time instead of runtime looks like a reasonable optimization to me.Moreover, once you want to do it in runtime, you have to add special magic isFinalizable(type). So we can add such an option (configurable from the command-line or property file) to the JIT. -- Mikhail Fursov
