On 8/24/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> 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 <xiaofeng.li@gmail.com> 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 <weldonwjw@gmail.com> wrote:
> > > On 8/23/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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 <weldonwjw@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
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
|