harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Fri, 13 Oct 2006 08:15:35 GMT
On 10/13/06, Rana Dasgupta <rdasgupt@gmail.com> 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

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