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

[Christine Flood]

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.

Christine

----- Original Message -----
> From: "Aleksey Shipilev" <shade at redhat.com>
> To: shenandoah-dev at openjdk.java.net
> Sent: Monday, September 19, 2016 4:26:33 PM
> Subject: Design question: why not reuse the CMS slots in mark word?
> 
> Hi,
> 
> I tried to search for the answer to this on my own, to no avail. Our
> current forwarding pointer is laid out before the object, which makes
> the allocation logic to reserve more space than "visible" to the object
> instance. Obviously, you would want to have the forwarding pointer
> within the object.
> 
> My question is: is there a reason we cannot reuse the mark word
> mechanics already laid out for CMS? See the bit format here:
>  http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/6bddcf692e1d/src/share/vm/oops/markOop.hpp#l30
> 
> It would seem that both 32 bit and 64 bit modes have the place for the
> forwarding pointer (cut alignment bits out):
>  //             PromotedObject*:29 ---------->| promo_bits:3 ----->|
> (CMS promoted object)
>  //  PromotedObject*:61 --------------------->| promo_bits:3 ----->|
> (CMS promoted object)
>  //  narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->|
> (COOPs && CMS promoted object)
> 
> Of course, we trade in monitor biasing, complicate hashcode storage, a
> bit slower forwarding, plus we need to support compressed forwarding
> pointers, but other than that? Maybe I miss some blocker issue, but
> somebody had explored and discovered it already?
> 
> Thanks,
> -Aleksey
> 
>