harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Artem Aliev" <artem.al...@gmail.com>
Subject Re: [drlvm][gc/threading] need the two lsb's from object header for MMTk port
Date Fri, 06 Oct 2006 12:50:42 GMT
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 <weldonwjw@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message