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.
cheers
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
