Robin Garner wrote:
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
Why is it necessary to piggyback on hashCode() for this? Just to keep
he GC from having the GC place requirements on object layout? (In which
case I'd argue that you are doing practically the same thing if you just
takeover hashCode())
> 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.
Are you agreeing that the GC should own hashCode() or that some header
bits are allowed? From a generalist POV, I liked the header bits idea,
but I know nothing about how GCs are done..
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
