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
 64.233.184.235 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:references;
        b=QmPQLlqBjVoqRehSiS+oO1Mc52x58aPmtlIx7HP39cYO8+XZKhnhQP+CGG98E/aUiYRRH0AOhCTOp/MY98Th9fpfeyoIwCSMVtcaiqiKhMSYwpma3nveDK2bP0oP/RnOR4XNGnMOw14eE2hjx36dxT7Qsgwp+FJDKqX/1qylw/g=
Message-ID: <4dd1f3f00609011249q1a0b64c4xeb6c2d3f7dcf6d5a@mail.gmail.com>
Date: Fri, 1 Sep 2006 12:49:00 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][VM] set_hash_bits() in
 vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?
In-Reply-To: <187bb05d0609010509l766e4308rf6054982343d7332@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_58252_28254858.1157140140332"
References: <4dd1f3f00608280832k9d62f20l803fdf10a0810d24@mail.gmail.com>
	 <12385bbd0608290152y12daa52eo2f1f4959186c9465@mail.gmail.com>
	 <187bb05d0609010509l766e4308rf6054982343d7332@mail.gmail.com>

------=_Part_58252_28254858.1157140140332
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/1/06, Artem Aliev <artem.aliev@gmail.com> wrote:
>
> Guys,
>
> The problem looks much broader then just a hash code placing.
> There is no common place that describe object header format and object
> header sharing protocol.


Yes, I noticed the same thing.  This was the original motivation for
starting these email threads on the topic.  Once we as a group have a good
handle on what functionality the header bits contains, we can then figure
out what flexibility needs to be built into the object model.

There are 3 components that use object header together.
> VMcore -- store VT pointer and hashcode
> ThreadManager -- update lockword
> GC -- tries to find unused bits for its own purpose
>          Different GC algorithms use different unused bits:
>           2-bits from aligned VT  pointer,
>           move hashcode to the synthetic field and use last byte
>           truncate hashcode
>
> So by moving hash_code() handling to GC and drop VT bit usage
> scenario, you simplify the problem to GC- TM interaction but not solve
> it.


>From the other email thread I started on the subject, Robin Garner and I
came to the conclusion that giving one byte of object header to the GC to do
Object.hashCode() plus whatever else the GC wants to do should be sufficient
for the foreseeable future.  I suspect the MMTk community would think the
same way.  This leaves 3 bytes on a 32-bit machine for threading (thread
lock ID, recursion count, etc.) and 7 bytes on a 64-bit machine (unless
header compression is a requirement.)

We still need the protocol.


Please tell me if the above covers the need for a protocol.

The other problem is the 64bit platforms.(for example EM64T).
> It looks natural to have 64bit VT and lockword on such platforms
>
> So we need not only sharing protocol bu also a more flexible object
> layout.


Yes, it would be nice to have an "expando" object layout.  From what I
recall we did a header size trade-off study using ORP about 5 years ago.  It
was a couple of percent performance delta when adding/subtracting 4 bytes
from the object header.  Going from 8-byte to 4-byte header is certainly
possible but probably makes the JVM real fragile since there is such
pressure on the precious header bits.  Going to 12 bytes costs a couple of
percentage points so there needs to be some compelling reason to burn the
extra bits -- I just don't know any compelling reasons.

Thanks
> Artem
>
> PS:
> At this time we have following 64bit object header fromat
> | ------------------ 32 bit -------------------|
>        Virtual Method Table pointer
> |------------- 22bit -------|------10bit-----|
> Monitor lockword bits         ^unused/hashcode/gc_bits
>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division

------=_Part_58252_28254858.1157140140332--