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)
Message-ID: <4307.220.236.173.70.1156764364.squirrel@sqmail.anu.edu.au>
In-Reply-To: <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.com>
References: <4dd1f3f00608232050t20b790calf75810d81e6cabcc@mail.gmail.com>
    <44EDD7FC.6040200@Intel.com>
    <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.com>
Date: Mon, 28 Aug 2006 21:26:04 +1000 (EST)
Subject: Re: [DRLVM][VM] -- which header bits are available for GC mark and
     GC forwarding use?
From: "Robin Garner" <robin.garner@anu.edu.au>
To: harmony-dev@incubator.apache.org
User-Agent: SquirrelMail/1.4.4-xss
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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

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