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 Mon, 28 Aug 2006 11:26:04 GMT
>                                                      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

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


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