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: domain of weldonwjw@gmail.com designates
 66.249.82.239 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MMfXVS1sd+0fhWtaNXDDIs4e6+sEVPS+yOWq4XbdH3ztplUpp0+Rq+53rhNO84yO4EFheJg6sNUuezZYN/yOdzn3b6LpQSnPWf5yqv97RbTnCwtsdjsA2uu1ZS+6bdiojFop3wfEDEVkwzyUw8mdcEyMckW1z8FCJTIevjQPNko=
Message-ID: <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.com>
Date: Thu, 24 Aug 2006 15:19:06 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][VM] -- which header bits are available for GC mark and GC
 forwarding use?
In-Reply-To: <44EDD7FC.6040200@Intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4dd1f3f00608232050t20b790calf75810d81e6cabcc@mail.gmail.com>
	 <44EDD7FC.6040200@Intel.com>

On 8/24/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> In any way, currently there is no single header file in the system,
> which would describe the object structure. Rather, DRLVM uses some
> static assumptions about object header, which are not enforced by any
> common include file. This would be a nice thing to solve...

Good point.  There needs to be a discussion on harmony-dev regarding
how the object header bits are "sliced and diced".  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.  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.  Are there any remaining
fields unaccounted for?  Thoughts?

-- 
Weldon Washburn
Intel Middleware Products Division

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