Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of artem.aliev@gmail.com designates
 64.233.162.192 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sZqxyV/sdLQZWS/7UyfP20UywGogTeOWDMpNuYIP2tdZge92/pLOScN11T0Q21LFS2fL3OSpn4EBwLEXOD2z+yJbnAYhiW09cr6wZISnvrgrcbcKjAYPpgsfCf2XOTDiMQSvLCv7xhCovpIc8or2PZKb8wyGYG1rIw4J4gapPOk=
Message-ID: <187bb05d0609010509l766e4308rf6054982343d7332@mail.gmail.com>
Date: Fri, 1 Sep 2006 16:09:19 +0400
From: "Artem Aliev" <artem.aliev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM][VM] set_hash_bits() in
 vmcore/src/thread/mon_enter_exit.cpp -- is it a bug or a feature?
In-Reply-To: <12385bbd0608290152y12daa52eo2f1f4959186c9465@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4dd1f3f00608280832k9d62f20l803fdf10a0810d24@mail.gmail.com>
	 <12385bbd0608290152y12daa52eo2f1f4959186c9465@mail.gmail.com>

Guys,

The problem looks much broader then just a hash code placing.
There is no common place that describe object header format and object
header sharing protocol.
There are 3 components that use object header together.
VMcore -- store VT pointer and hashcode
ThreadManager -- update lockword
GC -- tries to find unused bits for its own purpose
          Different GC algorithms use different unused bits:
           2-bits from aligned VT  pointer,
           move hashcode to the synthetic field and use last byte
           truncate hashcode

So by moving hash_code() handling to GC and drop VT bit usage
scenario, you simplify the problem to GC- TM interaction but not solve
it.

We still need the protocol.

The other problem is the 64bit platforms.(for example EM64T).
It looks natural to have 64bit VT and lockword on such platforms

So we need not only sharing protocol bu also a more flexible object layout.

Thanks
Artem

PS:
At this time we have following 64bit object header fromat
| ------------------ 32 bit -------------------|
        Virtual Method Table pointer
|------------- 22bit -------|------10bit-----|
  Monitor lockword bits         ^unused/hashcode/gc_bits


On 8/29/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> This is the GC_V4 specifics. It uses two bits of least significant
> byte of the status word during GC, but it always return zeros to this
> bits after GC.
>
> Here is the atomic way to do the changes:
>   do {
>      unsigned char lsb = *P_HASH_CONTENTION(p_obj);
>      unsigned char new_lsb = lsb | hb;
>      unsigned char uptodate_lsb =
>           port_atomic_cas8(P_HASH_CONTENTION(p_obj), new_lsb, lsb);
>   while (lsb != uptodate_lsb);
>
> BTW, atomic operations is only needed if GC wants to update those two
> bits during mutator work. Otherwise, non-atomic operations is ok, as
> the same value can be safely written to the same address by multiple
> threads. This is one pros for moving this code to GC.
>
> --
> Ivan
>
> On 8/28/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > While porting MMTk to harmony/drlvm, I hit an integration problem.  It
> > could even be a bug.  set_hash_bits() assumes the least significant
> > bit is zero.  Assuming that the LSB can be "owned" by the garbage
> > collector for its purposes, set_hash_bits() will fail if the GC sets
> > this bit to one.  Somehow I think the code should read the target
> > location, create the intended bit pattern before attempting to do the
> > atomic compare and swap.  Currently the code assume the target CAS
> > location holds zero.
> >
> > SInce I am working only in single thread right now, I hacked around
> > the problem with the below.  Thoughts?
> >
> >
> > C:\t_harmony\drlvm\trunk\vm\vmcore\src\thread>svn diff mon_enter_exit.cpp
> > Index: mon_enter_exit.cpp
> > ===================================================================
> > --- mon_enter_exit.cpp  (revision 425482)
> > +++ mon_enter_exit.cpp  (working copy)
> > @@ -368,7 +368,12 @@
> >          hb = (23 & HASH_MASK);  // NO hash = zero allowed, thus hard map hb = 0
> >  to a fixed prime number
> >
> >      // don't care if the cmpxchg fails -- just means someone else already set t
> > he hash
> > -    port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
> > +    //port_atomic_cas8(P_HASH_CONTENTION(p_obj),hb, 0);
> > +    unsigned char lsb = *P_HASH_CONTENTION(p_obj);
> > +    lsb = lsb & 0x01;  //wjw need to keep the LSB, its used by MMTk Garbage Col
> > lector
> > +    hb = hb | lsb;
> > +    if ( (*P_HASH_CONTENTION(p_obj) & HASH_MASK) == 0 ) // wjw non-atomic hack
> > for now
> > +        *P_HASH_CONTENTION(p_obj) = hb;
> >  }
> >
>
> ---------------------------------------------------------------------
> 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