32 bits header and alignment slack

[Kennke, Roman]

Hello Remi,

>>> Hello,
>>> I was try to read the code corresponding to the compact identity hashcode
>>> https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode
>>> 
>>> But I did not see any mention of the fact that due to object alignment, there is
>>> maybe already an empty 32 bits space at the end of the object.
>>> By example, with a java.lang.Integer and a 64 bits header, due to alignment to
>>> 64 bits, there is 32 bits of space which is not used after the value of the
>>> Integer
>>> 
>>> j.l.Integer layout
>>> mark word / 64 bits
>>> value / 32 bits
>>> empty / 32 bits
>>> 
>>> In that case, when System.identityHashCode() is called, it could use that space
>>> directly instead of waiting the GC to move the object to another location of
>>> the mostly same size.
>>> 
>>> Obviously, there is a good chance that this is exactly what the VM currently
>>> does and I've just missed that part :)
>> 
>> I have not called it out separately, but it’s mentioned in side-sentences, like:
>> 
>> "The first call to System.identityHashCode() transitions the hash-bits from the
>> 00 state to the 01 state, *if there is no sufficient alignment gap at the end
>> of the object,* and return the computed i-hash.”
>> 
>> The current prototype does it that way.
>> https://github.com/openjdk/lilliput/pull/137
>> 
>> I’ll write it down more specifically.
>> 
>> Thanks for pointing out!
> 
> Thinking a little more about it.
> The aligment gap is not necessary at the end of the object, a j.l.Long with a 32 bits header has a 32 bits gap in between the mark/class word and the field containing the value.

This is a very good point, and a nice improvement! And should not be very difficult to implement, either.

Thanks for suggesting that!

Roman



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