8345659: Fix broken alignment after ReservedSpace splitting in GC code

[stefank]

The Serial and Parallel GCs create a ReservedSpace for the total heap and then splits it into a young generation ReservedSpace and an old generation ReservedSpace. The latter operation creates an ReservedSpace with an alignment that doesn't match the base address. This bug is benign because the ReservedSpaces are short-lived and we don't look at the alignment. However, if we are to add stricter checks when creating ReservedSpaces we need to fix this.

Tested with tier1-3

---

Progress

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

Issue

• JDK-8345659: Fix broken alignment after ReservedSpace splitting in GC code (Enhancement - P4)

Reviewers

• Albert Mingkun Yang (@albertnetymk - Reviewer)
• Axel Boldt-Christmas (@xmas92 - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22602

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22602.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

[openjdk]

@stefank 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:

8345659: Fix broken alignment after ReservedSpace splitting in GC code

Reviewed-by: ayang, aboldtch

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 69 new commits pushed to the master branch:

• 076bfa6: 8345656: Move os alignment functions out of ReservedSpace
• 2826838: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
• c9ec271: 8345800: Update copyright year to 2024 for serviceability in files where it was missed
• 8e0f929: 8345805: Update copyright year to 2024 for other files where it was missed
• f88c1c6: 8345773: Class-File API debug printing capability
• e88e793: 8343148: C2: Refactor uses of "PhaseValue::con() + PhaseIdealLoop::set_ctrl()" into separate method
• 1e9204f: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390 code
• c40140e: 8334581: Remove no-arg constructor BasicSliderUI()
• 8de0622: 8345767: javax/swing/JSplitPane/4164779/JSplitPaneKeyboardNavigationTest.java fails in ubuntu22.04
• abcd23f: 8334756: javac crashed on call to non-existent generic method with explicit annotated type arg
• ... and 59 more: https://git.openjdk.org/jdk/compare/5cc150c63632c3ab8bf23d94f941d3b6db45d55c...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

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

[openjdk]

@stefank The following label will be automatically applied to this pull request:

• hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (6c5cf2e2)
• 00: Full (e4eba9a8)

[albertnetymk]

I wonder if doing the same for first_part makes it more symmetric/readable.

[stefank]

I wonder if doing the same for first_part makes it more symmetric/readable.

I think it is unclear if that would help readability or not. The first_part reserved space has the same base as the heap_rs, so it is kind of natural that it inherits the alignment from heap_rs. To me it seems somewhat redundant to explicitly specifying HeapAlignment again. Any other reviewers that prefer one or the other way?

[albertnetymk]

I meant sth like heap_rs.first_part(MaxNewSize, GenAlignment);; then, both generations can check they are compliant wrt GenAlignment. Checking the HeapAlignment compliance, it should be done before this; at another abstraction level.

[stefank]

You are right, that seems like a good thing to do.

[xmas92]

lgtm.

The alignment always require extra thinking as it has multiple meanings. It is both the required alignment of the base, but it is also the granularity / alignment of the size. But we have the same meaning when it comes to HeapAlignment, SpaceAlignment and GenAlignment. So the partition size does not break this invariant.

It is unfortunate that we do not assert that these invariants are maintained when we partition a reserved space. Something like:

ReservedSpace::ReservedSpace(char* base, size_t size, size_t alignment, size_t page_size,
                             bool special, bool executable) : _fd_for_heap(-1) {
  assert((size % os::vm_allocation_granularity()) == 0,
         "size not allocation aligned");
+ assert(alignment != 0, "must be set");
+ assert(size % alignment == 0, "must be");
+ assert((uintptr_t)base % alignment == 0, "must be");
  initialize_members(base, size, alignment, page_size, special, executable);
}

But I know you are working on refactoring and improving the ReservedSpace. Let us hope we can make this more robust in the future.

[stefank]

but it is also the granularity / alignment of the size

I don't think that this is a strict requirement throughout the JVM's usage of ReservedSpace. AFAIU, the alignment only strictly applies to the base pointer, but some users has also has an 'alignment' requirement (as opposed to a 'page_size' requirement) on the size. Let's take an extra round thinking about that for the ReservedSpace rewrites.

But I know you are working on refactoring and improving the ReservedSpace. Let us hope we can make this more robust in the future.

Yes, I have extra verification in my other patch.

[stefank]

Thanks both for reviewing!

[xmas92]

I don't think that this is a strict requirement throughout the JVM's usage of ReservedSpace. AFAIU, the alignment only strictly applies to the base pointer, but some users has also has an 'alignment' requirement (as opposed to a 'page_size' requirement) on the size.

Yes, the users might not have these requirements, but the current implementation of ReservedSpace enforces it. It might be nice to separate these two properties.

AFAICT all paths go through ReservedSpace::reserve which assert(is_aligned(size, alignment), "Size must be aligned to the requested alignment"); and all three cases ensures that base is aligned, and if the succeed they call initialize_members.

Of course _alignment can be 0 if we have no reservation. But calling partition / last_part / first_part is then not allowed (the same is true most ReservedSpace member functions).

We have uses from the outside that do not care about the alignment, and they will get some page_size (or os::vm_allocation_granularity()) as their alignment.

[stefank]

All good points, Axel.

[stefank]

So, for completeness of the discussion. AFAICT, we have partition, last_part, first_part, and space_for_range that all completely skips verifying against alignment. The intention is to try to enforce the alignment in an up-coming RFE.

[stefank]

/integrate

[openjdk]

Going to push as commit c34b87c.
Since your change was applied there have been 74 commits pushed to the master branch:

• e294899: 8345647: Fix recent NULL usage backsliding in Shenandoah
• d381d58: 8332268: C2: Add missing optimizations for UDivI/L and UModI/L and unify the shared logic with the signed nodes
• 45c914c: 8343607: C2: Shenandoah crashes during barrier expansion in Continuation::enter
• a21d21f: 8345609: [C1] LIR Operations with one input should be implemented as LIR_Op1
• 2382a2d: 8345661: Simplify page size alignment in code heap reservation
• 076bfa6: 8345656: Move os alignment functions out of ReservedSpace
• 2826838: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
• c9ec271: 8345800: Update copyright year to 2024 for serviceability in files where it was missed
• 8e0f929: 8345805: Update copyright year to 2024 for other files where it was missed
• f88c1c6: 8345773: Class-File API debug printing capability
• ... and 64 more: https://git.openjdk.org/jdk/compare/5cc150c63632c3ab8bf23d94f941d3b6db45d55c...master

Your commit was automatically rebased without conflicts.

[openjdk]

@stefank Pushed as commit c34b87c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.