8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout #1407

fparain · 2025-03-24T20:49:25Z

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.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

JDK-8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout (Enhancement - P3)

Reviewers

Coleen Phillimore (@coleenp - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla.git pull/1407/head:pull/1407
$ git checkout pull/1407

Update a local copy of the PR:
$ git checkout pull/1407
$ git pull https://git.openjdk.org/valhalla.git pull/1407/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1407

View PR using the GUI difftool:
$ git pr show -t 1407

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1407.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-03-24T20:50:05Z

👋 Welcome back fparain! A progress list of the required criteria for merging this PR into lworld will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-03-24T20:51:01Z

@fparain This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout

Reviewed-by: coleenp

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the lworld branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the lworld branch, type /integrate in a new comment.

merykitty · 2025-05-13T13:35:19Z

This would forbid the class which contains the NULLABLE_NON_ATOMIC_FLAT from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field:

The holder is an identity class.
The holder is a large value class without @LooselyConsistentValue.

This is equally valid to null-restricted field of non-@LooselyConsistentValue, too.

bridgekeeper · 2025-07-08T20:13:44Z

@fparain This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

fparain · 2025-07-25T21:03:46Z

/keepalive

openjdk · 2025-07-25T21:05:01Z

@fparain The pull request is being re-evaluated and the inactivity timeout has been reset.

openjdk · 2025-07-25T21:05:46Z

@fparain this pull request can not be integrated into lworld due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout flat_final
git fetch https://git.openjdk.org/valhalla.git lworld
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge lworld"
git push

bridgekeeper · 2025-09-20T00:06:08Z

@fparain This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

mlbridge · 2026-01-09T16:39:48Z

Webrevs

fparain · 2026-01-09T20:13:29Z

This would forbid the class which contains the NULLABLE_NON_ATOMIC_FLAT from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field:
* The holder is an identity class.

* The holder is a large value class without `@LooselyConsistentValue`.
This is equally valid to null-restricted field of non-@LooselyConsistentValue, too.

Yes, there are some restrictions where the NULLABLE_NON_ATOMIC_FLAT can be used, see the comments and the can_use_atomic_flat argument in the field_layout_selection() method.

merykitty · 2026-01-10T11:46:30Z

I assume this PR is for flattening of nullable fields at immutable memory (strict final fields) only. But I think the same flattening can be done for null-free field, right?

merykitty · 2026-01-10T13:26:01Z

src/hotspot/share/classfile/classFileParser.hpp

                      _non_atomic_size_in_bytes(-1), _non_atomic_alignment(-1),
-                      _atomic_layout_size_in_bytes(-1), _nullable_layout_size_in_bytes(-1),
+                      _atomic_layout_size_in_bytes(-1), _nullable_atomic_layout_size_in_bytes(-1),
+                      _nullable_non_atomic_layout_size_in_bytes(-1),


Do we need nullable_non_atomic_alignment, similar to non_atomic_alignment. Besides, it may be better to rename the null_free fields, too.

coleenp

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

src/hotspot/share/classfile/fieldLayoutBuilder.cpp

coleenp · 2026-01-14T20:12:01Z

src/hotspot/share/oops/inlineKlass.cpp

      break;
+    case LayoutKind::NULLABLE_NON_ATOMIC_FLAT:
+      assert(has_nullable_non_atomic_layout(), "Layout not available");
+      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)

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

Nullable non-atomic layouts have the same alignment constraint as null_free_non_atomic layouts.
Null-free non atomic layouts have an alignment constraint based on the constraints of individual fields inside the layout. The addition of the null marker, which is currently encoded with a byte, just adds the weakest alignment constraint to the set of constraints to be considered, so it has no effect, and the end results for nullable-non-atomic layouts is the same as for null-free-non-atomic layouts.

coleenp · 2026-01-14T20:12:20Z

src/hotspot/share/oops/inlineKlass.cpp

      break;
    case LayoutKind::NULL_FREE_ATOMIC_FLAT:
-      return has_atomic_layout();
+      return has_null_free_atomic_layout();


This was a good renaming.

coleenp · 2026-01-14T20:14:07Z

src/hotspot/share/oops/inlineKlass.hpp

+    int _null_free_non_atomic_alignment;     // alignment requirement for null-free non-atomic layout
+    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
+    int _nullable_atomic_size_in_bytes;   // size and alignment requirement for a nullable layout (always atomic), -1 if no nullable flat layout is possible
+    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?

Can you align the // s please?

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?

An InlineKlass supports a set of layout according to its own characteristics (number of fields, atomicity, etc.).
When computing the layout of a container with a value field, the JVM looks at the characteristics of the field (static, final , strict, null-free, etc.) and the layouts available for this InlineKlass and selects the best one that satisfies all requirements.

src/hotspot/share/oops/layoutKind.hpp

fparain · 2026-01-16T13:54:52Z

This would forbid the class which contains the NULLABLE_NON_ATOMIC_FLAT from being flattened into a class which contains it. I think we should only do so if the holder of the flattened strict final field should not be flattened if it is not itself a strict final field:
* The holder is an identity class.

* The holder is a large value class without `@LooselyConsistentValue`.
This is equally valid to null-restricted field of non-@LooselyConsistentValue, too.

Yes, there are some restrictions where the NULLABLE_NON_ATOMIC_FLAT can be used, see the comments and the can_use_atomic_flat argument in the field_layout_selection() method.

I assume this PR is for flattening of nullable fields at immutable memory (strict final fields) only. But I think the same flattening can be done for null-free field, right?

Strict final null-free fields could also be flattened without having to be concerned about atomicity, but null-freeness is not part of JEP 401. So this case is not supported in this PR. It can be added later when the null-restriction JEP has been finalized.

coleenp

Looks good!

src/hotspot/share/classfile/fieldLayoutBuilder.cpp

coleenp

Looks good!

NULLABLE_NON_ATOMIC_FLAT support in runtime and interpreter

276eb40

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Jul 25, 2025

Merge remote-tracking branch 'upstream/lworld' into flat_final

fcdd929

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Oct 24, 2025

fparain added 5 commits November 19, 2025 08:29

Merge remote-tracking branch 'upstream/lworld' into flat_final

9f08020

Fix build after merge

a0b07a5

Merge remote-tracking branch 'upstream/lworld' into flat_final

09fb110

Add empty values case and some LayoutKindHelper cleanup

c95d2c3

Merge remote-tracking branch 'upstream/lworld' into flat_final

ef1bf8f

openjdk bot added the merge-conflict Pull request has merge conflict with target branch label Dec 17, 2025

fparain added 4 commits January 7, 2026 09:19

Merge remote-tracking branch 'upstream/lworld' into flat_final

7cf6b3d

Improve tests

ff4add9

Merge remote-tracking branch 'upstream/lworld' into flat_final

5f74877

Fix compilation

55f6c47

openjdk bot removed the merge-conflict Pull request has merge conflict with target branch label Jan 8, 2026

fparain changed the title ~~Adding flattening of strict final fields~~ 8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout Jan 8, 2026

fparain added 2 commits January 8, 2026 10:51

Fix Copyright years

cf29d02

Cleanups and fixes

972768c

fparain marked this pull request as ready for review January 9, 2026 16:33

openjdk bot added the rfr Pull request is ready for review label Jan 9, 2026

merykitty reviewed Jan 10, 2026

View reviewed changes

More renaming

91c57ec

coleenp reviewed Jan 14, 2026

View reviewed changes

Fix coding style

7654118

coleenp approved these changes Jan 16, 2026

View reviewed changes

src/hotspot/share/classfile/fieldLayoutBuilder.cpp Show resolved Hide resolved

openjdk bot added the ready Pull request is ready to be integrated label Jan 16, 2026

fparain mentioned this pull request Jan 16, 2026

8374729: [lworld] Enabling CDS crash with UseAltSubstitutabilityMethod #1903

Closed

3 tasks

fparain added 2 commits January 21, 2026 13:54

Merge remote-tracking branch 'upstream/lworld' into flat_final

3c5cd97

Fix to work with JDK-8374729

eab559d

coleenp approved these changes Jan 21, 2026

View reviewed changes

8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout #1407

Are you sure you want to change the base?

8374800: [lworld] Add a NULLABLE_NON_ATOMIC_FLAT layout #1407

Conversation

fparain commented Mar 24, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Mar 24, 2025

Uh oh!

openjdk bot commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

merykitty commented May 13, 2025

Uh oh!

bridgekeeper bot commented Jul 8, 2025

Uh oh!

fparain commented Jul 25, 2025

Uh oh!

openjdk bot commented Jul 25, 2025

Uh oh!

openjdk bot commented Jul 25, 2025

Uh oh!

bridgekeeper bot commented Sep 20, 2025

Uh oh!

mlbridge bot commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

fparain commented Jan 9, 2026

Uh oh!

merykitty commented Jan 10, 2026

Uh oh!

merykitty Jan 10, 2026

Choose a reason for hiding this comment

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coleenp Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

fparain Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

coleenp Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

coleenp Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

coleenp Jan 14, 2026

Choose a reason for hiding this comment

Uh oh!

fparain Jan 16, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

fparain commented Jan 16, 2026

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

fparain commented Mar 24, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Mar 24, 2025 •

edited

Loading

mlbridge bot commented Jan 9, 2026 •

edited

Loading