Weldon, All
Here is the updated vm/vmcore/sync_bit.h header file.
That, I think, describes current state of the object header.
I olso try define rules: How to update the header correctly.
Welcome to discussion on them.
#ifndef _sync_bits_H
#define _sync_bits_H
/**
* These defines describe the current state of the object header (object_info)
* (the second DWORD of any java object)
*
* Here is except form the object_layout.h:
* typedef struct ManagedObjectCompressedVtablePtr {
uint32 vt_offset;
uint32 obj_info;
*
* The obj_info(also known as obj_header, lockword) is mostly used
for java monitor implementation (22bit) in ThreadManager. The other 10
bits could be shared among other components.
* At this time, the vmcore uses 6 bits to store hash code, and GC
uses some bits for marking purposes.
*
* Because there are 3 component that share the same DWORD.
* Here is a rules for this header usage.
*
* Rationale:
* The monitor implementation uses CAS32 (lock cmpxcg) to set the LOCK_ID bits.
* (acquires lock). if LOCK_ID is equals THREAD_ID of the current thread,
* the dword is updated with regular store command (for example in
monitor exit)
* So to update the other header bits carefully anyone should follows
next rules:
*
* 1. All updates should be done in hythread_suspend_disable().
* Elsewhere the GC could move the object while you are preparing for
* writing.
* 2. It is safe to update the field in there stop_the_world_fase of GC
* (after hythread_suspend_all_threads() call). No one else
actives at that point.
* 3. It is safe to update, if the thread is the owner of the object monitor
* hythread_thin_monitor_get_owner(header_ptr) == hythread_self().
* 3a. The monitor owner could be suspended or monitor could be
acquired, before the update in case of 3.
* 4. If the monitor have been inflated to fat monitor,
* hythread will not update the header. So you could update it.
* is_fat_monitor(*header_ptr) == TRUE.
*
* 5. in case of 3 or 4, it is recommended to use CAS, because more
then one thread could still update the header.
* 6. if THREAD_ID==0, the monitor is not owned or reserved, CAS
should be used to update data.
*
*
*/
// the TM monitor implementation bits.
// 11111111 11111111 11111100 00000000
#define LOCKWORD_MASK (0xffffffff ^ 0x3FF)
// THREAD_ID
#define THREAD_ID_MASK (0xffff0000)
// 6bit default hashcode
// 00000000 00000000 00000000 01111110
// custom hashcode algorithm could free these bits
#define HASH_MASK 0x7e
// free bits for GC usage
// 00000000 00000000 00000011 10000001
#define GC_BIT_MASK (0xffffffff ^ (LOCKWORD_MASK | HASH_MASK))
Thanks
Artem
On 10/6/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
From reading current svn HEAD, it looks like thread_native_thin_monitor.c
reserves the bottom 10 bits of the object's lock word for object hashcode.
If this is true, I'd like to take the bottom two bits for MMTk port. Please
tell me what #defines I need to change to make this happen.
Thanks
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
