Sharing the markword (aka Valhalla's markword use)

[Remi Forax]

----- Original Message -----
> From: "Roman Kennke" <rkennke at amazon.de>
> To: "Dan Heidinga" <dan.heidinga at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>, "lilliput-dev" <lilliput-dev at openjdk.org>
> Sent: Tuesday, March 5, 2024 4:31:59 PM
> Subject: 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://github.com/openjdk/jdk/pull/17755)
> - 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://github.com/openjdk/lilliput/pull/137)
> 
> For a descriptions of our current plans (which are likely to change until we’re
> done), see the JEP:
> https://openjdk.org/jeps/450
> 

For the compact identity hashcode, i wonder if for arrays the hashCode storage should be always present.
Independantly of Valhalla, relocating a big array just for the hashCode does not seem to be a good strategy, and it also exacerbates the allocation failure issue.
In that case, is_flat_array and is_null_free_array can be bits that share the same storage as the hashCode. 

> Thanks,
> Roman
> 

Rémi

> 
>> 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://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69
> 
> 
> 
> 
> 
> 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