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

[Roman Kennke]

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