harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Fri, 01 Sep 2006 06:18:15 GMT
Weldon Washburn wrote:
> Robin,
> Good points.  Given that Object.hashCode() implementation sortof,
> kindof depends on a copying mature space, does it make sense for the
> GC to "own" the Object.hashCode() implementation?  That way, we
> eliminate the vm-wide debate about giving object hash one or two or
> even 12 header bits.  

Absolutely.  +1

 >                                  It all becomes a local problem of GC
> implementation.  No need for negotiating with the rest of the VM :)
>  From a top-level how about giving the GC one byte of object header to
> do hash plus whatever it wants?  I realize it would be nice to have an
> "expando" object model in Harmony that would allow arbitrary number of
> header bits for a) tib ptr, b) default hash code, c) lock info and d)
> GC info.  I worry that this would be too disruptive to the code base
> right now.  Can we make do with the above proposal?

We can definitely make do with it.

> Just to be clear, the two-bit Object.hashCode() scheme I refer to is
> the one in section 3.3 of, "Space- and Time-Efficient Implemention of
> the Java Object Model" by David Bacon, et al.  I think this is also
> the scheme Ivan Volosyuk is refering to and has an implementation of.

And as implemented in JikesRVM.  Yep, that's the one I'm talking about 
too.  So where you say

 >> >                                       I think the hashCode can be
 >> > reduced to one bit plus the object's current address at first
 >> > HashCode() invocation.  I'd put this hash bit in the GC byte.  And
 >> > make the GC byte the lowest byte in the header word.  The remaining
 >> > 3bytes could be used for fat/thin locks.

I'm guessing you're assuming a copying nursery and a non-moving mature 
space ?  In a more general setting I'm not sure how you could get away 
with one bit.


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message