harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Thu, 24 Aug 2006 14:07:14 GMT
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


Mime
View raw message