Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 01 Sep 2006 16:18:15 +1000
From: Robin Garner <robin.garner@anu.edu.au>
Subject: Re: [DRLVM][VM] -- which header bits are available for GC mark and GC
 forwarding use?
In-reply-to: <4dd1f3f00608280728x1e3253d7odf2b1b7a26ef5362@mail.gmail.com>
To: harmony-dev@incubator.apache.org
Message-id: <44F7D0A7.5030609@anu.edu.au>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <4dd1f3f00608232050t20b790calf75810d81e6cabcc@mail.gmail.com>
 <44EDD7FC.6040200@Intel.com>
 <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.com>
 <4307.220.236.173.70.1156764364.squirrel@sqmail.anu.edu.au>
 <4dd1f3f00608280728x1e3253d7odf2b1b7a26ef5362@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060728)

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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org