JDK-8317831 : compiler/codecache/CheckLargePages.java fails on OL 8.8 with unexpected memory string
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2023-10-10
  • Updated: 2024-06-17
  • Resolved: 2023-12-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 21 JDK 22
17.0.13-oracleFixed 21.0.5-oracleFixed 22 b27Fixed
Related Reports
Relates :  
JDK-8304954 - SegmentedCodeCache fails when using large pages
Relates :  
JDK-8318482 - problemlist compiler/codecache/CheckLargePages.java on Linux-x64 until JDK-8317831 is fixed
Relates :  
JDK-8319795 - Static huge pages are not used for CodeCache
Sub Tasks
JDK-8318482 :  
problemlist compiler/codecache/CheckLargePages.java on Linux-x64 until JDK-8317831 is fixed - Resolved
Description
Test uses -Xlog:pagesize=info option to check huge page info, then performs some checks on the resulting output. One of the checks is that the page size is expected to end with B, K, M or G, but does not account for the fact that it could end with a period "."
In the most recent OL 8.8 update the page size contains period at the end (example: 1G.)

Not sure at this point whether this is a test issue or platform configuration issue. 
------------ Relevan test output
  Expected memory string '1G. DEFAULT LARGE PAGE SIZE: 1G.'to end with either of: B, K, M, G
    Test expects: DEFAULT LARGE PAGE SIZE: 1G
    Actual: DEFAULT LARGE PAGE SIZE: 1G.
Comments
Fix request [17u] I backport this for parity with 17.0.13-oracle. No risk, only tests change. Clean backport. Test pass. SAP nightly testing passed.
14-06-2024
Fix request [21u] I backport this for parity with 21.0.5-oracle. No risk, only a test change. Clean backport. Test pass. SAP nightly testing passed.
14-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2576 Date: 2024-06-13 05:50:49 +0000
13-06-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/713 Date: 2024-06-13 05:38:53 +0000
13-06-2024
Changeset: 86b27b78 Author: Yi-Fan Tsai <yftsai@amazon.com> Committer: David Holmes <dholmes@openjdk.org> Date: 2023-12-06 02:34:26 +0000 URL: https://git.openjdk.org/jdk/commit/86b27b784e20f7cdadd241f7feedd024482baa8f
06-12-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16962 Date: 2023-12-05 01:08:10 +0000
05-12-2023
The test should be fixed after JDK-8319795. It went more complicated than originally expected.
04-12-2023
[~yftsai] any update on this? Would be nice to get the fix into JDK 22 to be able to un-problem list the test. Thanks!
04-12-2023
Hi Yi-Fan. I haven't worked on it yet. Feel free to reassign it to yourself. Thanks!
09-11-2023
Hi Damon, have you worked on this? I've looked into it and can prepare the fix. JDK-8261894 removed UseHugeTLBFS from CodeCache::page_size, and JDK-8310233 changed the pagesize log.
08-11-2023
Assuming that this is a test bug: ILW = Test fails due to unexpected VM output (test bug), single test on OL, no workaround = MLH = P4
19-10-2023
Damon, could you please have a look? Thanks.
19-10-2023
I believe that the failing test should be able to handle configurations with more than one usable page size. Specifically it should be able to handle the period at the end of the output, as JVM is producing such output: [0.001s][info][pagesize] Large page support enabled. Usable page sizes: 4k, 2M. Default large page size: 2M. My initial investigation is complete. Assigning to Compiler sub-component to investigate the test, since the test belongs to JVM Compiler. It is possible also this could be a JVM bug, in which case this could be further reassigned.
19-10-2023
------- Before upgrade: Platform: Oracle Linux Server 8.7 (5.15.0-8.91.4.1.el8uek.x86_64) JDK: jdk-22+20-1525 java -Xlog:pagesize=info -XX:+UseLargePages -version ... [0.001s][info][pagesize] Static hugepage support: [0.001s][info][pagesize] hugepage size: 2M [0.001s][info][pagesize] hugepage size: 1G [0.001s][info][pagesize] default hugepage size: 2M [0.001s][info][pagesize] Transparent hugepage (THP) support: [0.001s][info][pagesize] THP mode: always [0.001s][info][pagesize] THP pagesize: 2M [0.001s][info][pagesize] JVM will attempt to prevent THPs in thread stacks. [0.001s][info][pagesize] Using the default large page size: 2M ... ------- After upgrade: Platform: Oracle Linux Server 8.8 (5.15.0-104.119.4.2.el8uek.x86_64) JDK: jdk-22+20-1525 java -Xlog:pagesize=info -XX:+UseLargePages -version ... [0.001s][info][pagesize] Static hugepage support: [0.001s][info][pagesize] hugepage size: 2M [0.001s][info][pagesize] hugepage size: 1G [0.001s][info][pagesize] default hugepage size: 2M [0.001s][info][pagesize] Transparent hugepage (THP) support: [0.001s][info][pagesize] THP mode: always [0.001s][info][pagesize] THP pagesize: 2M [0.001s][info][pagesize] JVM will attempt to prevent THPs in thread stacks. [0.001s][info][pagesize] Using the default large page size: 2M [0.001s][info][pagesize] UseLargePages=1, UseTransparentHugePages=0 [0.001s][info][pagesize] Large page support enabled. Usable page sizes: 4k, 2M. Default large page size: 2M.
19-10-2023