On 9/1/06, Artem Aliev <[EMAIL PROTECTED]> 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
