[External] : Re: Sharing the markword (aka Valhalla's markword use)

[Dan Heidinga]

4 free bits – just what we need! =)

One of the challenges for J9 over the last few years has been finding header bits.  J9 went to a “single word header”, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they’re put per class (layout gaps are a pretty common choice).  This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases.

Small headers are good but how small is small enough?  This isn’t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project’s ability to use bits.  There’s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously.

--Dan

From: Thomas Stüfe <thomas.stuefe at gmail.com>
Date: Tuesday, March 5, 2024 at 11:29 AM
To: Dan Heidinga <dan.heidinga at oracle.com>
Cc: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>, Kennke, Roman <rkennke at amazon.de>
Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
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<https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/128__;!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV1vyUKLi$>
[2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/<https://urldefense.com/v3/__https:/fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/__;!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV5vWqERE$>

Cheers, Thomas

On Tue, Mar 5, 2024 at 4:06 PM Dan Heidinga <dan.heidinga at oracle.com<mailto: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<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV4DF62Mv$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240306/93a65632/attachment.htm>