harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] The first GC helper with fast-path implemented in Java: gc_alloc
Date Fri, 13 Oct 2006 07:55:25 GMT
My indentation is messed up, but it's too late to correct it..


On 10/12/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
>
> On 10/12/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > 3) The problem: Is the signature for gc_alloc method : gc_alloc(int
> > > objSize,
> > > > int allocationHandle) is universal for all GCs?
> > > > I think it's not. But we can extend JIT with different signatures
> > > support if
> > > > needed.
> > >
> > >


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.


> > 5) The magic code in does not contain 'finalizable' check.
> > > > JIT can do this check during the compilation and do not generate the
> > > fast
> > > > path. This is another option to pass to JIT from GC.
> > >
> > > Yes, this is good. Let's drop the allocationHandle. I am not using it
> in
> > > GCv5.
> >
> >


 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. Getting rid of the TLS parameter on the other hand,  is a good idea.

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