Sharing the markword (aka Valhalla's markword use)

[Dan Heidinga]

(Cross-posting to both valhalla-dev and lilliput-dev)

Valhalla’s markword usage and Lilliput’s desire to shrink the object header require some careful collaboration to find a design that let’s both projects move forward.  I’d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput’s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together – hence the cross-post.

Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:

* is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.

* is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn’t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a “substitutability” test is required.

For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.

Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).

We use two bits to identify the special cases of arrays:

* is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.

* is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.

Arrays – being identity objects – need both their hash codes and locking bits.

This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we’re working on reconfirming those results.

How does this approach fit with the current Lilliput plans?

--Dan

[0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240305/1472fa42/attachment.htm>