harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Fri, 01 Sep 2006 13:23:02 GMT

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


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