RFR: 8372150: Parallel: Tighten requirements around heap sizes with NUMA and Large Pages [v3]

Joel Sikström jsikstro at openjdk.org
Mon Nov 24 11:01:21 UTC 2025


> Hello,
> 
> Today, Parallel decides to opt out of using Large pages if the heap size, either minimum, initial or maximum, does not cover enough Large pages for all spaces. Additionally, if we don't get enough heap size for at least one OS page per MutableNUMASpace (one per NUMA-node), Parallel decides to run in a NUMA-degraded mode, where it skips allocating memory locally for some NUMA-nodes. Both of these issues are problematic if we want to start the JVM with a default initial heap size that is equal to the minimum heap size (see [JDK-8371986](https://bugs.openjdk.org/browse/JDK-8371986)). To solve this, we should consider making sure that the minimum heap size is always enough to cover precisely one page per space, where the page size may be Large or not.
> 
> For completeness, when user-provided settings for UseNUMA, UseLargePages and heap sizes can't be satisfied at the same time, one must be prioritised over others. Today, we prioritise heap size settings over both UseNUMA and UseLargePages. This change suggest shifting the (primary) priority to UseNUMA and UseLargePages, by bumping MinHeapSize, InitialHeapSize and MaxHeapSize to an adequate number, if not already enough. By bumping the minimum heap size to an adequate number, we are also bumping the lower-limit for the initial heap size and maximum heap size, which must be equal to or greater than the minimum heap size.
> 
> However, a problem with this approach is that if the Large page size is very large (e.g., 512MB or 1GB), the minimum, initial, and maybe the maximum heap size will be bumped to a very large number as well. To mitigate this impact, we look at what Large page size can be used based on the maximum heap size instead. This is because, running the JVM in default configuration, the maximum heap size will almost always be large enough to cover enough Large pages, so we bump the minimum and initial to that value instead. But, if the maximum heap size is not enough, we opt-out of using Large pages, which is consistent with the old behavior.
>  
> <details>
> 
> <summary><b>Min and Initial heap sizes before/after</b> (expandable section)</summary>
> 
> Before changes. We always get Min&Initial 2MB that we request:
> 
> java -XX:+UseParallelGC -Xms2M -Xmx1G
> Alignments: Space 512K, Heap 2M
> Heap Min Capacity: 2M
> Heap Initial Capacity: 2M
> 
> java -XX:+UseParallelGC -XX:+UseLargePages -Xms2M -Xmx1G
> MinHeapSize (2097152) must be large enough for 4 * page-size; Disabling UseLargePages for heap
> Alignments: Space 512K, Heap 2M...

Joel Sikström has updated the pull request incrementally with three additional commits since the last revision:

 - Choose large page size based on MaxHeapSize
 - Revert "8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages"
   
   This reverts commit c02e08ade597193d70d1eb21036845bdd0304d51.
 - Revert "Albert review feedback"
   
   This reverts commit 66928d22112c1ac516e4b654c28249fdedf0dba9.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28394/files
  - new: https://git.openjdk.org/jdk/pull/28394/files/66928d22..232f1a70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28394&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28394&range=01-02

  Stats: 195 lines in 16 files changed: 111 ins; 64 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/28394.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28394/head:pull/28394

PR: https://git.openjdk.org/jdk/pull/28394


More information about the hotspot-dev mailing list