[lworld] RFR: 8341757: Field layout computation allowing atomic and nullable flattening

[Dan Heidinga]

On Mon, 21 Oct 2024 21:07:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Sorry, I may be slow today but I would expect j.l.Byte and j.l.Short/Char to have different field layouts - given a 12byte header, the `value` field of j.l.Byte can start at the first free byte.  Using hand-hacked versions of the print fields output:
>> 
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 "value" B
>> 
>> and the `value` field of a j.l.Short needs additional alignment:
>> 
>>  @0 RESERVED 12/-
>>  @12 PADDING 4/1
>>  @16 REGULAR 2/2 "value" S
>> 
>> 
>> What am I missing?
>
> I don't know why, but we don't have the same layouts.
> Here's the ones I have without support for NULLABLE_ATOMIC_FLAT:
> 
> 
> Layout of class java/lang/Byte at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 "value" B
> 
> 
> 
> Layout of class java/lang/Short at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 2/2 "value" S
> 
> 
> 
> Layout of class java/lang/Integer at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 4/4 "value" I
> 
> 
> And the layouts of the same classes with NULLABLE_ATOMIC_FLAT enabled:
> 
> 
> Layout of class java/lang/Byte at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 "value" B
>  @13 NULL_MARKER 1/1
> 
> 
> 
> Layout of class java/lang/Short at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 2/2 "value" S
>  @14 NULL_MARKER 1/1
> 
> 
> 
> Layout of class java/lang/Integer at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 PADDING 4/1
>  @16 REGULAR 4/4 "value" I
>  @20 NULL_MARKER 1/1

Thanks Fred.  I think I get it now.  With the pre-valhalla layouts, the j.l.Integer takes 32 bits for the payload so it can start at `@12` and have the correct alignment.  In the Valhalla case, we need the 4bytes of padding to get the 64 bit payload (32 bit int + null marker) aligned correctly to be read atomically.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1810675469