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 ivan.volosyuk@gmail.com
 designates 64.233.166.180 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=kZ10K4f+vK+sX+FjoewVHrgLT5JYt0Fut6oeEBfus1XwuKX06qoXY9nR6zSuPRXRjsllVe7FgNCLVbzcWU7lRWKWml3RkVpsViqTvhvUxALpIyujApTzPRIs4e8MyIitCy4FN1aEMgCoNp92+zmf/BA0QWzKHCD6gwnEQJD1wGo=
Message-ID: <12385bbd0608250210ie9d40ej3765af16662295a8@mail.gmail.com>
Date: Fri, 25 Aug 2006 13:10:42 +0400
From: "Ivan Volosyuk" <ivan.volosyuk@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: <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.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>
	 <4dd1f3f00608241519q4d02b314l9b2106c648985cd4@mail.gmail.com>

Weldon, look at the patch in http://issues.apache.org/jira/browse/HARMONY-1269.
I have already done this work. After the patch you have whole lowest
byte + 2 bits in the second byte for GC use; in expense of
implementing hashcode by GC.

In my understanding the hashcode can be reduced to 2 status bits in object info:
  00. hashcode is not set
  01. hashcode is set (hashcode is the address of object)
  11. hashcode is set and object is moved (hashcode is no longer the
address of object)

This layout require assistance from GC (which is missing in GC_V4).

I suggest using interface function: gc_get_hashcode() in GC-to-VM
interface which will know exactly the layout of bits in the lowest
byte of hashcode and will do all the needed actions depending on the
GC implementation.
--
Regards,
Ivan

On 8/25/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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