8257588: Make os::_page_sizes a bitmask

[tabata-d]

JDK-8257588 is an enhancement aims to improve the internal handling of page sizes within the HotSpot JVM.

The fix was originally implemented in JDK 16. We are now backporting it to JDK 11.

Unclean Backport

• The backport was not entirely clean due to the introduction of utility functions related to power-of-two calculations. Specifically, the powerOfTwo.hpp header, which centralizes these utilities in later JDK versions (introduced by JDK-8234331), was not present in JDK 11.
• A full backport of powerOfTwo.hpp would bring in a lot of code unnecessary for JDK-8257588, so it should not be imported as-is.
• Instead of a full backport of powerOfTwo.hpp, a highly targeted integration was performed. Only the precise powerOfTwo utility functions essential for JDK-8257588's operation (e.g., max_power_of_2_size_t, log2_size_t, round_down_power_of_2_size_t) were selectively extracted and adapted. These minimal, required functions were then strategically placed within the existing src/hotspot/share/utilities/globalDefinitions.hpp file in the JDK 11 backport.
• I also need to fix solaris.cpp, which is not in the mainline.

Testing

System: Red Hat Enterprise Linux 9.4 (x86_64).
gtest: All 25 tests in the gtest:os/server suite, including those directly related to os::PageSizes, passed successfully.
jtreg: All 672 tests in the hotspot_runtime group and all 12 tests in the vmTestbase_largepages group passed successfully.

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

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
• JDK-8257588 needs maintainer approval

Issue

• JDK-8257588: Make os::_page_sizes a bitmask (Enhancement - P4 - Requested)

Reviewers

• Paul Hohensee (@phohensee - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk11u-dev.git pull/3160/head:pull/3160
$ git checkout pull/3160

Update a local copy of the PR:
$ git checkout pull/3160
$ git pull https://git.openjdk.org/jdk11u-dev.git pull/3160/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3160

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk11u-dev/pull/3160.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back dtabata! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 04: Full - Incremental (9d9d613d)
• 03: Full - Incremental (3ad71094)
• 02: Full - Incremental (147b8ae1)
• 01: Full - Incremental (21395ffa)
• 00: Full (bec487f0)

[ptribble]

This will also need updates to os_solaris.cpp - the original fix wouldn't include that, because Solaris had been removed from mainline at the time of the original change.

[ptribble]

Thanks. It's a bit more complicated than that, Solaris uses page sizes more widely. This ends up being quite a significant change as a result.

Just the error lines for a build log with this patch applied on illumos, which should identify the other functions that need fixing:

src/hotspot/os/solaris/os_solaris.cpp:2278:30: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2279:42: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2280:25: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2792:36: error: 'page_sizes_max' was not declared in this scope; did you mean 'page_sizes'?
src/hotspot/os/solaris/os_solaris.cpp:2792:23: error: cannot convert 'os::PageSizes' to 'size_t*' {aka 'long unsigned int*'} in argument passing
src/hotspot/os/solaris/os_solaris.cpp:2798:16: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2802:58: error: no matching function for call to 'os::trace_page_sizes(const char [21], os::PageSizes&, int&)'
src/hotspot/os/solaris/os_solaris.cpp:2814:29: error: cannot convert 'os::PageSizes' to 'size_t*' {aka 'long unsigned int*'}
src/hotspot/os/solaris/os_solaris.cpp:2818:39: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2821:16: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2821:35: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2823:14: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'const int')
src/hotspot/os/solaris/os_solaris.cpp:2824:14: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2826:18: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'const int')
src/hotspot/os/solaris/os_solaris.cpp:2826:37: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2828:31: error: cannot convert 'os::PageSizes' to 'size_t*' {aka 'long unsigned int*'}
src/hotspot/os/solaris/os_solaris.cpp:2830:27: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2832:61: error: no matching function for call to 'os::trace_page_sizes(const char [18], os::PageSizes&, int)'
src/hotspot/os/solaris/os_solaris.cpp:2847:30: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')
src/hotspot/os/solaris/os_solaris.cpp:2848:20: error: no match for 'operator[]' (operand types are 'os::PageSizes' and 'int')

[openjdk]

⚠️ @tabata-d This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[tabata-d]

@ptribble I've created a fix for Solaris. Unfortunately, I don't have a Solaris environment. Could you please check if it builds without any issues?

[ptribble]

Thanks. I've successfully built the latest commit on Solaris, and a quick test is clean.

[tabata-d]

GHA: macos-aarch64 and macos-x64 are failing in the build

For target hotspot_variant-server_libjvm_gtest_objs_precompiled_precompiled.hpp.pch:
error: invalid argument '-std=gnu23' not allowed with 'C++'
For target hotspot_variant-server_libjvm_objs_precompiled_precompiled.hpp.pch:
error: invalid argument '-std=gnu23' not allowed with 'C++'

At the time of the third commit in this pull request, all GHA runs were green. After that, I only merged the latest changes from master and added Solaris-specific fixes. Therefore, I believe the macOS build failures are not caused by the changes in this pull request.

[tabata-d]

@phohensee Could I trouble you to review this once again?

[phohensee]

I'm not a Solaris expert, but looks reasonable.

[tabata-d]

/template append

[openjdk]

@tabata-d The pull request template has been appended to the pull request body

[bridgekeeper]

@tabata-d This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 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!

[tabata-d]

/touch

[openjdk]

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

[tstuefe]

General questions/comments:

I see you have opened a whole range of backports for THP issues and tests, often patches from me originally. I see at least these:

#3160
#3171
#3172
#3194
#3195
#3210
#3211
#3212

There may be more. Please also provide information on which one of these had already been backported by Oracle, which may be a point to consider.

What is the overarching theme/reason here? Please explain the end goal. Please also provide a plan for how you want to deal with errors that will invariably happen as long as not the full chain of follow-up patches are backported.

(If I had to guess I would say you want to fix 8312182 ? If so, I wonder whether there is a simpler workaround for these old releases instead of having to backport this long chain of unclean patches.)

Update releases (especially 11 and 8) are very stable releases in which we usually limit ourselves to only very important fixes or security patches.

Cheers, Thomas

[gnu-andrew]

General questions/comments:

I see you have opened a whole range of backports for THP issues and tests, often patches from me originally. I see at least these:

#3160 #3171 #3172 #3194 #3195 #3210 #3211 #3212

There may be more. Please also provide information on which one of these had already been backported by Oracle, which may be a point to consider.

What is the overarching theme/reason here? Please explain the end goal. Please also provide a plan for how you want to deal with errors that will invariably happen as long as not the full chain of follow-up patches are backported.

(If I had to guess I would say you want to fix 8312182 ? If so, I wonder whether there is a simpler workaround for these old releases instead of having to backport this long chain of unclean patches.)

Update releases (especially 11 and 8) are very stable releases in which we usually limit ourselves to only very important fixes or security patches.

Cheers, Thomas

Thanks Thomas. This pretty much sums up what I was going to say as well. It is too much risk to backport every change as is, which is also demonstrated by some of the PRs being fixes for issues created by the preceding PRs. We should focus on what the actual bug is we want to fix and find the most maintainable solution for that without major changes.

[tabata-d]

The end goal is to fix JDK-8312182 in OpenJDK 8.
A user has encounterd a critical issue that JDK-8312182 causes physical memory exhaustion on their system, leading to non-Java processes being terminated by the OOM-Killer.

While some workarounds are conceivable, a fundamental solution is fixing JDK-8312182.

• JDK-8312182: THPs cause huge RSS due to thread start timing issue

To backport JDK-8312182 to 11, the following two prerequisite fixes are necessary:

• JDK-8310233: Fix THP detection on Linux
• JDK-8257588: Make os::_page_sizes a bitmask

And, regressions that have already been fixed upstream also need to be backported. I have reviewed all "relates to" issues for JDK-8312182, JDK-8310233, and JDK-8257588 on JBS and determined that the following should be backported:

Regressions for JDK-8257588:

• JDK-8257989: Error in gtest os_page_size_for_region_unaligned after 8257588

Regressions for JDK-8310233:

• JDK-8312394: [linux] SIGSEGV if kernel was built without hugepage support
• JDK-8312620: WSL Linux build crashes after JDK-8310233

Regressions for JDK-8312182:

• JDK-8314139: TEST_BUG: runtime/os/THPsInThreadStackPreventionTest.java could fail on machine with large number of cores

Finally, the parameter name added in JDK-8312182 will be changed to align with upstream:

• JDK-8312585: Rename DisableTHPStackMitigation flag to THPStackMitigation

---

Risk:
Since these include several unclean backports, the risk is high for 11, which is a very stable release.
However, I believe these patches should be backported because JDK-8312182 is a bug that might affects the entire user system, including non-Java processes.

---

Testing:
All hotspot/jtreg tests passed in Linux x64.

[tabata-d]

Hi, @tstuefe @gnu-andrew .
Thanks for your comments.

There may be more. Please also provide information on which one of these had already been backported by Oracle, which may be a point to consider.

Looking at JBS, it seems Oracle has not backported a series of fixes to 11.
In the past, #2086 has issued, but it was not integrated.

What is the overarching theme/reason here? Please explain the end goal.

I have described it in #3160 (comment).

Please also provide a plan for how you want to deal with errors that will invariably happen as long as not the full chain of follow-up patches are backported.

I plan to backport the full chain of follow-up patches. I have already issued backport PRs for the regreesion fixed upstream.

(If I had to guess I would say you want to fix 8312182 ? If so, I wonder whether there is a simpler workaround for these old releases instead of having to backport this long chain of unclean patches.)

It is too much risk to backport every change as is, which is also demonstrated by some of the PRs being fixes for issues created by the preceding PRs. We should focus on what the actual bug is we want to fix and find the most maintainable solution for that without major changes.

I think it would be safer to backport all prerequisite fixes and regression fixes whenever possible. Recently, the assertion made in openjdk/jdk8u-dev#808 , "Unclean backport but should be fairly safe in prep for a cleaner backport of JDK-8284047." seems to align with my way of thinking.
If there are many unclean parts and the risk is high, should we consider a simpler solution, even if it's different from upstream?

[jerboaa]

The end goal is to fix JDK-8312182 in OpenJDK 8. A user has encounterd a critical issue that JDK-8312182 causes physical memory exhaustion on their system, leading to non-Java processes being terminated by the OOM-Killer.

I'm objecting to backporting this series of patches. Here (in JDK 11) and even more so for JDK 8u. Clearly those bugs must have existed for years. We cannot fix every potential bug. Why is the user using THP to begin with?

While some workarounds are conceivable, a fundamental solution is fixing JDK-8312182.

For some bugs that's the "better" option, rather than putting every other user who doesn't run into that bug at risk. An alternative is to upgrade the JVM (to 17).

[tstuefe]

Lets continue discussion in the backport for JDK-8312182 #3210. I added my thoughts and some more questions for @tabata-d over there: #3210 (comment)

[tabata-d]

After the discussion in #3210, I have decided to close this PR.