harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Mon, 28 Aug 2006 14:43:35 GMT
+1, for GC to own Object.hashCode(). That's exactly, what I propose.

Slightly outdated patch with the changes included can be found in HARMONY-1269.
I can update it to reflect recent TM changes or you can redo this work
by yourself.
--
Thanks,
Ivan

On 8/28/06, Weldon Washburn <weldonwjw@gmail.com> 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.  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.

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