harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Thu, 24 Aug 2006 16:46:52 GMT
Weldon Washburn 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?

Yes. This is correct for the current GC (aka v4), see vm/gc/src/gc_header.h
     48 //
     49 // Use the contention bit of object header to lock stuff for now... Is t        his
OKAY???
     50 //
     51 #define GC_OBJECT_MARK_BIT_MASK 0x00000080
     52 #define FORWARDING_BIT_MASK 0x1

The comment is outdated. Bit 0x80 of the lockword has not been
used as a contention for quite some time.

GC v4 uses bit 0x80 for verification purpose.

> 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...)

In any way, currently there is no single header file in the system,
which would describe the object structure. Rather, DRLVM uses some
static assumptions about object header, which are not enforced by any
common include file. This would be a nice thing to solve...

> 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?

No. 
gc_header.h is correct in stating that GC v4 uses bit 0x80.

However, other GC implementation have other assumptions, and Ivan
recently submitted a patch (along with GC v4.1) that abstracts hashcode,
and makes all lower 10 bits available for GC use, provided that GC
serves the hashcode.

RESUME: If a GC provides function gc_get_hashcode(),
GC has 10 lower bits of lockword at its disposal.
Otherwise, it can only use bits 0,7,8,9 (bits 1-6 are used by default hash implementation).

One more thing to take into account, that current thread manager
may access lockword in another thread (e.g. using 32 bit compare-and-swap operation
to unreserve a lock), so atomic operation needs to be used
when updating lockword while java threads are running.

For example, see how default hashcode is implemented in vm/vmcore/src/thread/object_generic.cpp:
     57 void set_hash_bits(ManagedObject *p_obj)
     58     {
     59     uint8 hb = (uint8) (((POINTER_SIZE_INT)p_obj >> 3) & HASH_MASK)  ;
     60     // lowest 3 bits are not random enough so get rid of them
     61 
     62     if (hb == 0)
     63         hb = (23 & HASH_MASK);  // NO hash = zero allowed, thus hard map     
   hb = 0 to a fixed prime number
     64 
     65     // don't care if the cmpxchg fails -- just means someone else alread        y
set the hash
 *** 66     port_atomic_cas8(P_HASH_CONTENTION_BYTE(p_obj),hb, 0);
     67 }


---------------------------------------------------------------------
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