8346005: Parallel: Incorrect page size calculation with UseLargePages #26700

albertnetymk · 2025-08-08T14:50:06Z

Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: alignment and os-page-size. These are now represented as two fields in PSVirtualSpace.

The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation.

The size of any space is always aligned to alignment, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, alignment is always greater than or equal to os-page-size.

When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in ParallelScavengeHeap::initialize detects the OS page size in use and adjusts alignment if necessary.

Test: tier1–8

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-8346005: Parallel: Incorrect page size calculation with UseLargePages (Bug - P4)

Reviewers

Joel Sikström (@jsikstro - Reviewer)
Francesco Andreuzzi (@fandreuz - Author)

Contributors

Joel Sikström <jsikstro@openjdk.org>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26700

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

Using diff file

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

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-08-08T14:50:59Z

👋 Welcome back ayang! 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 · 2025-08-08T14:52:11Z

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

8346005: Parallel: Incorrect page size calculation with UseLargePages

Co-authored-by: Joel Sikström <jsikstro@openjdk.org>
Reviewed-by: jsikstro, fandreuzzi

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

c867971: 8369527: NMT: print malloc-site when a malloc'd memory detected as corrupted
7392360: 8369811: ZGC: Robust NUMA configuration detection
ee35320: 8370071: Clarify jcmd Thread.print help message
... and 94 more: https://git.openjdk.org/jdk/compare/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7...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 · 2025-08-08T14:53:18Z

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

hotspot

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.

albertnetymk · 2025-08-08T14:53:25Z

/cc hotspot-gc

openjdk · 2025-08-08T14:54:19Z

@albertnetymk
The hotspot-gc label was successfully added.

mlbridge · 2025-08-08T14:57:20Z

Webrevs

albertnetymk · 2025-09-08T08:39:53Z

Minor updates after JDK-8366434, as the page-size of reserved-memory reflects the intended/actual OS page-size, when using transparent huge pages.

albertnetymk · 2025-09-29T18:55:41Z

/cc hotspot-gc

albertnetymk · 2025-09-29T19:08:05Z

/touch

openjdk · 2025-09-29T19:26:04Z

@albertnetymk
The hotspot-gc label was successfully added.

openjdk · 2025-09-29T19:31:19Z

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

jsikstro

Reviewing this is taking some time, so this is not a full review yet, but so far I have some comments:

Why do we need the dance with Parallel being able to set a specific desired_page_size in Universe::reserve_heap()? Maybe I'm wrong, but would it not work to disable UseLargePages early and not have specific logic for Parallel?

jsikstro · 2025-09-22T12:05:53Z

src/hotspot/share/gc/parallel/psVirtualspace.hpp

  // ReservedSpace passed to initialize() must be aligned to this value.
  const size_t _alignment;

+  // OS page size used. If using transparent large pages, it's the desired large page-size.


I'd change this to say Transparent Huge Pages instead.

jsikstro · 2025-10-02T08:01:38Z

src/hotspot/share/gc/parallel/mutableSpace.hpp


- public:
+protected:
+  size_t page_size() const                           { return _page_size;         }


We should vertically align this with the other blocks.

jsikstro · 2025-10-02T09:11:51Z

src/hotspot/share/gc/parallel/parallelArguments.cpp


+  if (page_sz == os::vm_page_size()) {
+    log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
+    return;


Wouldn't it make sense to do FLAG_SET_ERGO(UseLargepages, false) here since it is effectively disabled.

There are non-heap uses of UseLargePages as well. Here we concluded heap can't use large-page, but other systems still can.

I see, thank you.

jsikstro · 2025-10-02T09:16:42Z

src/hotspot/share/gc/parallel/parallelArguments.cpp

  assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
-  size_t new_alignment = align_up(page_sz, SpaceAlignment);
+  // Space is largepage-aligned.
+  size_t new_alignment = page_sz;


To me it looks like new_alignment will always be different from SpaceAlignment here. We could simplify this to the following:

SpaceAlignment = page_sz; // Redo everything from the start initialize_heap_flags_and_sizes_one_pass();

To me it looks like new_alignment will always be different from SpaceAlignment here.

Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

We discussed this offline, but if default_space_alignment() ever coincided with a Large page size, say 2MB, and 2MB large pages are chosen, SpaceAlignment would still be equal to default_space_alignment() and we would end up reserving small pages in ParallelScavengeHeap::initialize().

albertnetymk

Why do we need the dance with Parallel being able to set a specific desired_page_size in Universe::reserve_heap()?

Because heap contains subspaces (eden,from,to,old) which needs to be larger than a OS-page in Parallel. Maybe this doesn't have to be this way, but that's what Parallel NUMA relies on currently. It would be much more invasive to change that.

albertnetymk · 2025-10-02T09:52:50Z

src/hotspot/share/gc/parallel/parallelArguments.cpp


+  if (page_sz == os::vm_page_size()) {
+    log_warning(gc, heap)("MinHeapSize (%zu) must be large enough for 4 * page-size; Disabling UseLargePages for heap", MinHeapSize);
+    return;


There are non-heap uses of UseLargePages as well. Here we concluded heap can't use large-page, but other systems still can.

albertnetymk · 2025-10-02T10:02:50Z

src/hotspot/share/gc/parallel/parallelArguments.cpp

  assert(is_power_of_2((intptr_t)page_sz), "must be a power of 2");
-  size_t new_alignment = align_up(page_sz, SpaceAlignment);
+  // Space is largepage-aligned.
+  size_t new_alignment = page_sz;


To me it looks like new_alignment will always be different from SpaceAlignment here.

Why so? (I know the default value of SpaceAlignment is 64K*8 bytes, which is not a common large-page-size, but that info is not directly accessible in this context.)

albertnetymk · 2025-10-03T14:38:45Z

/contributor add jsikstro

openjdk · 2025-10-03T14:39:55Z

@albertnetymk
Contributor Joel Sikström <jsikstro@openjdk.org> successfully added.

jsikstro

I have a few small comments, but I think this looks pretty good now.

jsikstro · 2025-10-07T10:39:58Z

src/hotspot/share/gc/parallel/mutableNUMASpace.hpp

  void increment_samples_count()                     { ++_samples_count;          }

  size_t _base_space_size;
  void set_base_space_size(size_t v)                 { _base_space_size = v;      }


These are unused.

jsikstro · 2025-10-10T10:48:58Z

src/hotspot/share/gc/parallel/mutableNUMASpace.cpp

+    } else {
      if (i < lgrp_spaces()->length() - 1) { // Middle chunks
        MutableSpace *ps = lgrp_spaces()->at(i - 1)->space();
        new_region = MemRegion(ps->end(),
-                               ps->end() + (chunk_byte_size >> LogHeapWordSize));
+                               chunk_byte_size >> LogHeapWordSize);
      } else { // Top chunk
        MutableSpace *ps = lgrp_spaces()->at(i - 1)->space();
        new_region = MemRegion(ps->end(), end());
      }
+    }


This is technically fine, but maybe we can combine the else and the if to something like below to fit better with the comments?

if (i == 0) { // Bottom chunk ... } else if (i < lgrp_spaces()->length() - 1) { // Middle chunks ... } else { // Top chunk ... }

albertnetymk · 2025-10-21T08:11:03Z

Thanks for review.

/integrate

openjdk · 2025-10-21T08:13:09Z

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

ec13c28: 8366829: Add java.time.Duration constants MIN and MAX
430041d: 8367499: Refactor exhaustiveness computation from Flow into a separate class
b6b0f05: 8370262: Add jdk/javadoc/doccheck/checks/jdkCheckLinks.java to the ProblemList
... and 108 more: https://git.openjdk.org/jdk/compare/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-10-21T08:13:18Z

@albertnetymk Pushed as commit 2be273f.

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

pgc-largepage

0a67ca4

openjdk bot changed the title ~~8346005~~ 8346005: Parallel: Incorrect page size calculation with UseLargePages Aug 8, 2025

openjdk bot added the hotspot hotspot-dev@openjdk.org label Aug 8, 2025

openjdk bot added rfr Pull request is ready for review hotspot-gc hotspot-gc-dev@openjdk.org labels Aug 8, 2025

albertnetymk added 4 commits August 15, 2025 12:10

Merge branch 'master' into pgc-largepage

5df3735

Merge branch 'master' into pgc-largepage

88702f0

Merge branch 'master' into pgc-largepage

1b64a5e

page-size

74d4fa3

albertnetymk added 2 commits September 15, 2025 15:21

Merge branch 'master' into pgc-largepage

c725431

Merge branch 'master' into pgc-largepage

5c02c75

openjdk bot removed the hotspot-gc hotspot-gc-dev@openjdk.org label Sep 25, 2025

openjdk bot added the hotspot-gc hotspot-gc-dev@openjdk.org label Sep 29, 2025

jsikstro reviewed Oct 2, 2025

View reviewed changes

albertnetymk added 2 commits October 2, 2025 11:47

Merge branch 'master' into pgc-largepage

97cc91b

review

2ccd0dd

albertnetymk commented Oct 2, 2025

View reviewed changes

albertnetymk added 2 commits October 3, 2025 16:09

review

3227621

review

421f1c4

albertnetymk added 4 commits October 8, 2025 15:53

Merge branch 'master' into pgc-largepage

a84287d

review

a9c4cd0

Merge branch 'master' into pgc-largepage

e02d0bf

Merge branch 'master' into pgc-largepage

dca2661

jsikstro reviewed Oct 10, 2025

View reviewed changes

review

a6bafe7

jsikstro approved these changes Oct 10, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Oct 10, 2025

Merge branch 'master' into pgc-largepage

273c200

fandreuz approved these changes Oct 20, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Oct 21, 2025

openjdk bot closed this Oct 21, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 21, 2025

albertnetymk deleted the pgc-largepage branch October 21, 2025 08:14

8346005: Parallel: Incorrect page size calculation with UseLargePages #26700

8346005: Parallel: Incorrect page size calculation with UseLargePages #26700

Uh oh!

Conversation

albertnetymk commented Aug 8, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Aug 8, 2025

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

albertnetymk commented Aug 8, 2025

Uh oh!

openjdk bot commented Aug 8, 2025

Uh oh!

mlbridge bot commented Aug 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

albertnetymk commented Sep 8, 2025

Uh oh!

albertnetymk commented Sep 29, 2025

Uh oh!

albertnetymk commented Sep 29, 2025

Uh oh!

openjdk bot commented Sep 29, 2025

Uh oh!

openjdk bot commented Sep 29, 2025

Uh oh!

jsikstro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albertnetymk left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albertnetymk commented Oct 3, 2025

Uh oh!

openjdk bot commented Oct 3, 2025

Uh oh!

jsikstro left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

albertnetymk commented Oct 21, 2025

Uh oh!

openjdk bot commented Oct 21, 2025

Uh oh!

openjdk bot commented Oct 21, 2025

albertnetymk commented Aug 8, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Aug 8, 2025 •

edited

Loading

openjdk bot commented Aug 8, 2025 •

edited

Loading

mlbridge bot commented Aug 8, 2025 •

edited

Loading