harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Mon, 28 Aug 2006 14:28:16 GMT
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.  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?

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.

On 8/28/06, Robin Garner <robin.garner@anu.edu.au> wrote:
> >                                                      From talking to
> > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte
> > of object header for private use.  Its unclear to me if this will be a
> > performance problem for a product JVM.
>
> Yep.  We found a nice mark-sweep implementation technique that greatly
> reduces the cost of sweeping if we have several mark bits available, but
> after 4 or so bits the advantage tails off, so there is room for
> compromise with the VM's need.  On the other hand I'm currently looking at
> other ways we could speed up GC if there were a few extra header bits
> available, so the more bits available to GC, the better - and these will
> generally be tunable parameters that can be traded against the VM's other
> needs.
>
> >                                       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.
>
> In GenMS, where there is a copying nursery and a non-moving mature space,
> you could indeed get away with 1 bit for hashcode, with a different
> meeaning in each space.  In a heap where objects could move more than
> once, I think you might still need 2 bits.
>
> cheers
>
>
> ---------------------------------------------------------------------
> 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
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

---------------------------------------------------------------------
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


Mime
View raw message