Weldon, I have some information for this case. There bit layout was the following before new thread manager integration: object info word contains: 0 bit - available for GC 1-6 bits - object hashcode 7 bit - contention bit unused by TM, but used by GC_V4 8-31 bits - other thread manager's data
I have some changes for this layout in the GC v4.1 patch. Patch introduces new GC interface function: gc_get_hashcode() If garbage collector exports that function it hash full management of all bits in the lowest byte of object info word, but it should provide implementation of identity hashcode for heap objects. If garbage collector doesn't have this function, the previous (described above) layout of bits will be used. -- Ivan On 8/24/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Weldon, the bits your mentioned are for obj_info. Vtable can't have its bits overloaded simply without special handling. Thanks, xiaofeng On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > On 8/23/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > Weldon, I experimented with last two bits for marking and forwarding > > without problem. > > I assume you are referring to the 2 lowest bits in the vtable pointer. > The two lowest bits will step on the recursion mask in sync_bits.h... > won't it? I am confused. > > It turns out that MMTk keeps the mark bits around even between GCs. > Leaving an LSB of the vtable ptr set and then resuming application > execution will surely cause a failure. Thus there needs to be a full > time dedicated mark bit in the object header. This is in addition to > the need for a forwarding bit. > > > > > > The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. ( > > So far as I experimented, it's only used for heap verification). > > > > Thanks, > > xiaofeng > > > > On 8/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > > Looking at drlvm/trunk, it looks like vmcore/include/sync_bits.h > > > defines the use of *(ref_ptr +4) for 32-bit environment. Just > > > guessing that "#define BUSY_FORWARDING_OFFSET 0" is intended to tell > > > the GC that it can use the least significant bit out of these four > > > bytes. Is this correct? I would like to use this bit as an MMTk mark > > > bit. Will this work? (Actually the name, BUSY_FORWARDING_OFFSET is > > > probably not the best...) > > > > > > There is also a gc/src/gc_header.h file that contains, "#define > > > GC_OBJECT_MARK_BIT_MASK 0x80". This seems to step on top of > > > sync_bits.h use of this area??? Can I assume gc_header.h is > > > incorrect? > > > > > > -- > > > 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]
