Sharing the markword (aka Valhalla's markword use)

[Thomas Stüfe]

Hi Dan,

In addition to Roman's answer, we plan to reduce the Klasspointer to 22
bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and
still leave us with 4 unused bits.

Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this
year I think this is nowhere documented yet. I feel guilty but have been
swamped since returning from FOSDEM.

[1] https://github.com/openjdk/lilliput/pull/128
[2]
https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/

Cheers, Thomas

On Tue, Mar 5, 2024 at 4:06 PM Dan Heidinga <dan.heidinga at oracle.com> wrote:

> (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/b43e8265/attachment.htm>