[lworld] RFR: 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout [v2]

[Coleen Phillimore]

On Tue, 13 Jan 2026 21:29:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Strict final instance fields are not subject to concurrent writes during a read access, so they can be flattened even if they are nullable and bigger than 64 bits. The NULLABLE_NON_ATOMIC_FLAT layout is added for this particular case.
>> This new layout can also be used in the special case of nullable empty value classes, because their payload contains a single entry, the null-marker, which is naturally atomic.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More renaming

I have a couple questions and comments.  Looks good as an extension to the existing field layout design.

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1212:

> 1210:         _null_free_non_atomic_layout_alignment = _payload_alignment;
> 1211:       }
> 1212:       if (UseNullableValueFlattening) {

Could this be else if (UseNullableValueFlattening)?  These are mutually exclusive iirc so the else if would make that explicit.

src/hotspot/share/oops/inlineKlass.cpp line 175:

> 173:     case LayoutKind::NULLABLE_NON_ATOMIC_FLAT:
> 174:       assert(has_nullable_non_atomic_layout(), "Layout not available");
> 175:       return null_free_non_atomic_alignment();

Should this be nullable_non_atomic_alignment() ? Or is it the same alignment as null_free_non_atomic_alignment?  (if so pls comment why)

src/hotspot/share/oops/inlineKlass.cpp line 191:

> 189:       break;
> 190:     case LayoutKind::NULL_FREE_ATOMIC_FLAT:
> 191:       return has_null_free_atomic_layout();

This was a good renaming.

src/hotspot/share/oops/inlineKlass.hpp line 95:

> 93:     int _null_free_atomic_size_in_bytes;     // size and alignment requirement for a null-free atomic layout, -1 if no atomic flat layout is possible
> 94:     int _nullable_atomic_size_in_bytes;   // size and alignment requirement for a nullable layout (always atomic), -1 if no nullable flat layout is possible
> 95:     int _nullable_non_atomic_size_in_bytes; // size and alignment requirement for a nullable non-atomic layout, -1 if not available

Here is something that I'm confused about.  Does an InlineKlass have multiple possible layouts and sizes depending on the container?  Is that why the InlineKlass needs to save all these size non-static data members?

src/hotspot/share/oops/layoutKind.hpp line 69:

> 67: //             always be filled with zeros, and the default value could have its null marker set to non-zero if
> 68: //             it is used as a source to update a NULLABLE_ATOMIC_FLAT field.
> 69: // NULLABLE_NON_ATOMIC_FLAT: this is a special layout, only used for strict final non-static fields. Because strict

Can you capitalize 't' in "this" in these descriptions?

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

PR Review: https://git.openjdk.org/valhalla/pull/1407#pullrequestreview-3662553059
PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691869321
PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691888393
PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691889170
PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691894006
PR Review Comment: https://git.openjdk.org/valhalla/pull/1407#discussion_r2691902085