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.
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.
We still need the 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.
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
On 8/29/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
This is the GC_V4 specifics. It uses two bits of least significant
byte of the status word during GC, but it always return zeros to this
bits after GC.
Here is the atomic way to do the changes:
do {
unsigned char lsb = *P_HASH_CONTENTION(p_obj);
unsigned char new_lsb = lsb | hb;
unsigned char uptodate_lsb =
port_atomic_cas8(P_HASH_CONTENTION(p_obj), new_lsb, lsb);
while (lsb != uptodate_lsb);
BTW, atomic operations is only needed if GC wants to update those two
bits during mutator work. Otherwise, non-atomic operations is ok, as
the same value can be safely written to the same address by multiple
threads. This is one pros for moving this code to GC.
--
Ivan
On 8/28/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> While porting MMTk to harmony/drlvm, I hit an integration problem. It
> could even be a bug. set_hash_bits() assumes the least significant
> bit is zero. Assuming that the LSB can be "owned" by the garbage
> collector for its purposes, set_hash_bits() will fail if the GC sets
> this bit to one. Somehow I think the code should read the target
> location, create the intended bit pattern before attempting to do the
> atomic compare and swap. Currently the code assume the target CAS
> location holds zero.
>
> SInce I am working only in single thread right now, I hacked around
> the problem with the below. Thoughts?
>
>
> C:\t_harmony\drlvm\trunk\vm\vmcore\src\thread>svn diff mon_enter_exit.cpp
> Index: mon_enter_exit.cpp
> ===================================================================
> --- mon_enter_exit.cpp (revision 425482)
> +++ mon_enter_exit.cpp (working copy)
> @@ -368,7 +368,12 @@
> hb = (23 & HASH_MASK); // NO hash = zero allowed, thus hard map hb
= 0
> to a fixed prime number
>
> // don't care if the cmpxchg fails -- just means someone else already
set t
> he hash
> - port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
> + //port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
> + unsigned char lsb = *P_HASH_CONTENTION(p_obj);
> + lsb = lsb & 0x01; //wjw need to keep the LSB, its used by MMTk Garbage
Col
> lector
> + hb = hb | lsb;
> + if ( (*P_HASH_CONTENTION(p_obj) & HASH_MASK) == 0 ) // wjw non-atomic
hack
> for now
> + *P_HASH_CONTENTION(p_obj) = hb;
> }
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
