<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Aptos;
        panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-CA" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">The other three bits shouldn’t be required during GC and can be re-derived from the klass metadata.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif">--Dan<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">From:
</span></b><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">Kennke, Roman <rkennke@amazon.de><br>
<b>Date: </b>Tuesday, March 5, 2024 at 10:36</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"> </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">AM<br>
<b>To: </b>Dan Heidinga <dan.heidinga@oracle.com><br>
<b>Cc: </b>valhalla-dev@openjdk.org <valhalla-dev@openjdk.org>, lilliput-dev@openjdk.org <lilliput-dev@openjdk.org><br>
<b>Subject: </b>[External] : Re: Sharing the markword (aka Valhalla's markword use)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<span style="font-size:11.0pt">Hi Dan,<br>
<br>
Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-)<br>
<br>
I have two questions:<br>
- 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:
</span><a href="https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$"><span style="font-size:11.0pt">https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$</span></a><span style="font-size:11.0pt">
 )<br>
- 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:
</span><a href="https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode"><span style="font-size:11.0pt">https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode</span></a><span style="font-size:11.0pt"> and
</span><a href="https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$"><span style="font-size:11.0pt">https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$</span></a><span style="font-size:11.0pt">
 )<br>
<br>
For a descriptions of our current plans (which are likely to change until we’re done), see the JEP:<br>
</span><a href="https://openjdk.org/jeps/450"><span style="font-size:11.0pt">https://openjdk.org/jeps/450</span></a><span style="font-size:11.0pt"><br>
<br>
Thanks,<br>
Roman<br>
<br>
<br>
> On Mar 5, 2024, at 4:06 PM, Dan Heidinga <dan.heidinga@oracle.com> wrote:<br>
> <br>
> 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.<br>
> <br>
> (Cross-posting to both valhalla-dev and lilliput-dev)<br>
>  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.<br>
>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:<br>
>  * 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.<br>
>  * 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.<br>
>  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.<br>
>  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).<br>
>  We use two bits to identify the special cases of arrays:<br>
>  * 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.<br>
>  * 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.<br>
>  Arrays – being identity objects – need both their hash codes and locking bits.<br>
>  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.<br>
>  How does this approach fit with the current Lilliput plans?<br>
>  --Dan<br>
>  [0] </span><a href="https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$"><span style="font-size:11.0pt">https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$</span></a><span style="font-size:11.0pt">
<br>
<br>
<br>
<br>
<br>
<br>
Amazon Development Center Germany GmbH<br>
Krausenstr. 38<br>
10117 Berlin<br>
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss<br>
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B<br>
Sitz: Berlin<br>
Ust-ID: DE 289 237 879<br>
<br>
<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>