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][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Thu, 24 Aug 2006 15:56:09 GMT
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


Mime
View raw message