Design question: why not reuse the CMS slots in mark word?

[Christine Flood]

If we were willing to use a conditional read barrier, which we most definitively aren't, we could maintain the invariant that the mark word is always read from the to-space copy.  There would be some evil synchronization issues (especially with locked objects) but it's probably doable.

Christine

----- Original Message -----
> From: "Roman Kennke" <rkennke at redhat.com>
> To: "Aleksey Shipilev" <shade at redhat.com>, "Christine Flood" <chf at redhat.com>
> Cc: shenandoah-dev at openjdk.java.net
> Sent: Tuesday, September 20, 2016 5:18:42 AM
> Subject: Re: Design question: why not reuse the CMS slots in mark word?
> 
> Am Dienstag, den 20.09.2016, 10:53 +0200 schrieb Aleksey Shipilev:
> > On 09/19/2016 11:00 PM, Christine Flood wrote:
> > > 
> > > The theory was to make the read barrier as efficient as possible.
> > > It's always just a single read of a fixed offset.  If we tried to
> > > reuse the mark word we'd have to deal with locked objects and hash
> > > codes and all that nonsense potentially making read barriers much
> > > more expensive.
> > > 
> > > If you have a protocol that uses the mark word and doesn't
> > > introduce
> > > extra overhead in the common case (a conditional in a read barrier
> > > would be deadly) I'd love to hear it.
> > 
> > Okay, that makes sense, thanks.
> > 
> > Is this a hunch about the read barriers cost, or we actually tried
> > more
> > complicated read barriers? Trying to understand if potentially worth
> > investigating, or this road was taken already.
> 
> Very early on we tried to put the forwarding pointer in the mark word.
> We could handle most of the issues (hashcode, biased locking, etc) but
> the chief problem was displaced headers. This cannot be solved without
> making the read and write barriers, and the locking code significantly
> more complicated. As Christine said, if you can find a way to do it,
> we'd be happy to know :-)
> 
> CMS and other collectors can only use the mark word for forwarding
> pointers, because they stop the world. When storing the forwarding
> pointer, they temporarily store the current mark word on a side table
> and avoid those problems.
> 
> Roman
> 
>