Sharing the markword (aka Valhalla's markword use)

[Dan Heidinga]

Values lack identity so it’s possible for them to be deduplicated (or even duplicated!) at any point when they are not in the larval state.  That would mean we’d need the is_larval bit to be stable to any process (gc?) that may be responsible for (de)duplication.

The other three bits shouldn’t be required during GC and can be re-derived from the klass metadata.

--Dan

From: Kennke, Roman <rkennke at amazon.de>
Date: Tuesday, March 5, 2024 at 10:36 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>
Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
Hi Dan,

Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-)

I have two questions:
- Are there requirements/constraints on your side on the position of some of the bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to indicate self-forwarding in the GC. It kinda needs to be that bit, because we expect that the header can also be overlaid with a forwarding pointer, and those use all bits except the lowest 3. (See: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$> )
- Are any of the bits required during (full) GC? For example, in Lilliput, we want to make the hash-code use only 2 bits, and allocate the storage for the actual hash-code on-demand. However, this means that we need the hash-code bits to determine the object’s size, and therefore must not displace the hash-bits during GC (not even temporarily). This is also true for the Klass* bits, that we plan to go into the object header as well. (See: https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$<https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$> )

For a descriptions of our current plans (which are likely to change until we’re done), see the JEP:
https://openjdk.org/jeps/450

Thanks,
Roman


> On Mar 5, 2024, at 4:06 PM, Dan Heidinga <dan.heidinga at oracle.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
> (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://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$>





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240306/207f700e/attachment.htm>