On 10/9/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> Artem,
> I'd like to confirm what you said. For GC_BIT_MASK, it looks like the
> bottom
> two bits of byte number one is available for exclusive GC use. If the
GC
> needs to alter these two bits while the mutator(s)
Weldon Washburn wrote:
> Artem,
> I'd like to confirm what you said. For GC_BIT_MASK, it looks like the
> bottom
> two bits of byte number one is available for exclusive GC use. If the GC
> needs to alter these two bits while the mutator(s) are running, the GC
> needs
> to use CAS on the entire 32
Artem,
I'd like to confirm what you said. For GC_BIT_MASK, it looks like the bottom
two bits of byte number one is available for exclusive GC use. If the GC
needs to alter these two bits while the mutator(s) are running, the GC needs
to use CAS on the entire 32 bits of obj_info. Does this sound
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
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
