JDK-8324776 : runtime/os/TestTransparentHugePageUsage.java fails with The usage of THP is not enough
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 23
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2024-01-26
  • Updated: 2024-05-06
  • Resolved: 2024-04-29
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 23
23 b21Fixed
Related Reports
Relates :  
JDK-8325218 - gc/parallel/TestAlwaysPreTouchBehavior.java fails
Relates :  
JDK-8324781 - runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved
Relates :  
JDK-8315923 - pretouch_memory by atomic-add-0 fragments huge pages unexpectedly
Sub Tasks
JDK-8324785 :  
ProblemList two tests on linux due to JDK-8315923 - Resolved
Description
The following test fails in the JDK23 CI:

runtime/os/TestTransparentHugePageUsage.java

Here's a snippet from the log file:

#section:driver
----------messages:(7/273)----------
command: driver runtime.os.TestTransparentHugePageUsage
reason: User specified action: run driver runtime.os.TestTransparentHugePageUsage 
started: Fri Jan 26 17:19:01 UTC 2024
Mode: agentvm
Agent id: 33
finished: Fri Jan 26 17:19:02 UTC 2024
elapsed time (seconds): 0.793
----------configuration:(14/1894)----------

<snip>

----------System.out:(1/2085)----------
Command line: [/opt/mach5/mesos/work_dir/jib-master/install/jdk-23+8-499/linux-x64-debug.jdk/jdk-23/fastdebug/bin/java -cp /opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S36649/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/66225702-8d9e-445f-936d-273ad8a1e472/runs/b9c4d990-f663-41ad-9e51-0085eb44307b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/4/runtime/os/TestTransparentHugePageUsage.d:/opt/mach5/mesos/work_dir/jib-master/install/jdk-23+8-499/src.full/open/test/hotspot/jtreg/runtime/os:/opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S36649/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/66225702-8d9e-445f-936d-273ad8a1e472/runs/b9c4d990-f663-41ad-9e51-0085eb44307b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/4/test/lib:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jtreg.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/junit-platform-console-standalone-1.9.2.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/testng-7.3.0.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jcommander-1.82.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/guice-5.1.0.jar -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-x64/jdk-21_linux-x64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S36649/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/66225702-8d9e-445f-936d-273ad8a1e472/runs/b9c4d990-f663-41ad-9e51-0085eb44307b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/tmp -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch -Xlog:startuptime,pagesize,gc+heap=debug -XX:+UseSerialGC -Xms1G -Xmx1G runtime.os.TestTransparentHugePageUsage$CatSmaps ]
----------System.err:(11/667)----------
java.lang.RuntimeException: The usage of THP is not enough.
	at runtime.os.TestTransparentHugePageUsage.checkUsage(TestTransparentHugePageUsage.java:94)
	at runtime.os.TestTransparentHugePageUsage.main(TestTransparentHugePageUsage.java:59)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: The usage of THP is not enough.
Comments
Changeset: 8b8fb642 Author: Liming Liu <limingliu@os.amperecomputing.com> Committer: Thomas Stuefe <stuefe@openjdk.org> Date: 2024-04-29 15:14:37 +0000 URL: https://git.openjdk.org/jdk/commit/8b8fb6427e3cbc16b818ddcbd6a971f3d2370f94
29-04-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/18792 Date: 2024-04-16 08:57:48 +0000
16-04-2024
I applied an additional patch to your latest changes in an attempt to get the gtest pretouch_thp_fault_alloc executed in Mach5. I also enabled runtime/os/TestTransparentHugePageUsage.java and included the logs for those failures. The wrapper I created to try and get gtest pretouch_thp_fault_alloc running is: test/hotspot/jtreg/gtest/PretouchTHPGtests.java but Mach5 tells me that wrapper test did not execute. However, I did get failures from pretouch_thp_fault_alloc via other tests so it looks like something else in Mach5 made gtest pretouch_thp_fault_alloc execute. I really don't know how this gtest test subsystem works so I don't know why gtest pretouch_thp_fault_alloc didn't execute with my previous attempt and why it did execute with this run. I've attached the patch and the log files: $ unzip -l 20240324_patch_and_logs.zip Archive: 20240324_patch_and_logs.zip Length Date Time Name --------- ---------- ----- ---- 0 03-25-2024 13:50 20240324_patch_and_logs/ 108981 03-25-2024 13:48 20240324_patch_and_logs/TestTransparentHugePageUsage-linux-x64-debug.jtr 39680 03-25-2024 13:36 20240324_patch_and_logs/LargePageGtests.java#use-large-pages.jtr 55030 03-25-2024 13:45 20240324_patch_and_logs/NMTGtests.java#nmt-summary.jtr 44125 03-25-2024 13:39 20240324_patch_and_logs/NMTGtests.java#nmt-off.jtr 2907 03-25-2024 13:29 20240324_patch_and_logs/0001-enable-runtime-os-TestTransparentHugePageUsage.java-.patch 54990 03-25-2024 13:38 20240324_patch_and_logs/NMTGtests.java#nmt-detail.jtr 92014 03-25-2024 13:35 20240324_patch_and_logs/GTestWrapper.jtr 39868 03-25-2024 13:37 20240324_patch_and_logs/LargePageGtests.java#use-large-pages-1G.jtr 102150 03-25-2024 13:48 20240324_patch_and_logs/TestTransparentHugePageUsage-linux-aarch64-debug.jtr --------- ------- 539745 10 files
25-03-2024
[~qpzhang] - I executed a Mach5 Tier1 on the latest patch that you provided and there were no test failures. runtime/os/TestTransparentHugePageUsage.java did not execute in this run. I suspect that it's still on the ProblemList in the current patch. Verified: $ grep runtime/os/TestTransparentHugePageUsage.java test/hotspot/jtreg/ProblemList* test/hotspot/jtreg/ProblemList.txt:runtime/os/TestTransparentHugePageUsage.java 8324776 linux-all runtime/Thread/TestAlwaysPreTouchStacks.java did run and passed on all five platforms. I don't see any signs that the gtest pretouch_thp_fault_alloc executed in my Mach5 Tier1 job set either so I'm going to try running that test separately. Update: That didn't work. I get an error from Mach5: > Error: Test lookup failed for gtest:os_linux.pretouch_thp_fault_alloc Sorry, I don't know how to run this test via Mach5 and I don't have direct access to these machines. I don't have any more time to poke around with this for now, but I may later.
19-03-2024
Hi, [~dcubed], I am not sure if you could help run a gtest on the Oracle CI system. We want to check the counters of thp_fault_alloc/thp_fault_fallback from /proc/vmstat with below commit, on the UEK kernel v5.15 test system particularly. Thanks for the help in advance if you could run, and this can be the final experiment we could do before sending out a PR for review (to make the v5.4 tests pass only for the time being). gtest command: make test TEST="gtest:os_linux.pretouch_thp_fault_alloc" commit: https://github.com/limingliu-ampere/jdk/commit/bc83e19a682156ee7d09bf939c2b18f3d8c79e22
18-03-2024
Thanks. The latest test results proved that the failure [1] and [2] can PASS with the workaround on v5.4 and an issue had been filed to linux-uek [3] accordingly. While test [4] still failed and it may require further investigation to see if (madvise) pretouch on uek v5.15 would require any other special handling. [1] runtime/os/TestTransparentHugePageUsage.java on UEK kernel v5.4 [2] runtime/Thread/TestAlwaysPreTouchStacks.java on UEK kernel v5.4 [3] https://github.com/oracle/linux-uek/issues/23, MADV_DOEXEC and MADV_DONTEXEC should be redefined within a separate numerical range [4] runtime/os/TestTransparentHugePageUsage.java on UEK kernel v5.15 (x86 and aarch64)
11-03-2024
There were two test failures: runtime/os/TestTransparentHugePageUsage.java runtime/os/TestTransparentHugePageUsage.java I'm attaching the follow log files: -rw-r--r-- 1 dcubed staff 114816 Mar 8 11:31 TestTransparentHugePageUsage.log.202403031639 -rw-r--r-- 1 dcubed admin 104809 Mar 8 11:31 TestTransparentHugePageUsage.log.202403031650 runtime/Thread/TestAlwaysPreTouchStacks.java execute, but did not fail.
08-03-2024
[~qpzhang] - Sorry for the delay on this request. I was on holiday for much of the past two weeks. I had to update the patch to get it to apply due to changes to test/hotspot/jtreg/ProblemList.txt and I've started on Mach5 Tier1 job set.
03-03-2024
[~dcubed], Could you please help try this patch https://github.com/limingliu-ampere/jdk/commit/de9607ff64cc526bca9968b72a7065888c2f944d? We made a hacking for the madvise mode detection on UEK 5.4 kernel, and explicitly updated the VM flags on v5.15. Hopes there will be some change on the test results. Thanks a lot.
28-02-2024
See attached madvise_return_values.pdf, which compared the return values of madvise(0, 0, MADV_POPULATE_WRITE) call on different kernels. It confirmed that the MADV_DONTEXEC defined in UEKR6 5.4.17 accidentally used the duplicated number 23 as that of MADV_POPULATE_WRITE, and returned 0 unexpectedly. This is different from the defined function of Linux mainline 5.4 or latest 6.8-rc5. In addition, UEKR7 5.15.0 introduced the MADV_POPULATE_READ (22) and MADV_POPULATE_WRITE (23), and moved MADV_DOEXEC from 22 to 24, MADV_DONTEXEC from 23 to 25. As a quick conclusion, the reported regression is an issue particularly on UEK kernel 5.4.17. JDK-8324776, JDK-8324781, and JDK-8325218 may share the similar root cause. Some possible ways to solve the problem: 1). JVM to parse the version of Linux kernel then decide how to configure UseMadvPopulateWrite, 1 for 5.14+, otherwise 0. This dependency may lose effect due to any kernel feature backport. 2). JVM to tell “madvise(0, 0, 24) == 0” to decide if it runs on a kernel beyond UEK 5.4.17. The madvise mode 24 is supported on UEK 5.15 or Linux mainline 5.18-rc1 above. This might work but is very tricky, and Linux mainline 5.14 to 5.17 got skipped silently. 3). UEK kernel to update madvise numbers 22, 23 into a separate range from that being used by Linux mainline, for example 122, 123, to avoid the definition conflicts with those of Linux mainline. This would work for future potential conflicts on numbers 24 and 25 on UEK 5.15.0 too. Any other ideas or advice? BTW, the regression on UEK 5.15.0-105.125.6.2.1.el8uek needs further analysis.
21-02-2024
The UEK 5.4.17 kernel has different definition of the number 23 (MADV_DONTEXEC) from that of later version of mainline 23 (MADV_POPULATE_WRITE). This means this kernel version should be excluded no matter if the "madvise(0, 0, advice)" returns zero or non-zero. https://yum.oracle.com/repo/OracleLinux/OL8/UEKR6/x86_64/getPackageSource/kernel-uek-5.4.17-2136.322.6.2.el8uek.src.rpm include/uapi/asm-generic/mman-common.h #define MADV_DOEXEC 22 /* do inherit across exec */ #define MADV_DONTEXEC 23 /* don't inherit across exec */ introduced at https://github.com/oracle/linux-uek/commit/f7363f35f7961786e7ab8330205a462acffe11c0 vs. https://github.com/torvalds/linux/commit/4ca9b3859dac14bbef0c27d00667bb5b10917adb v5.14-rc1 include/uapi/asm-generic/mman-common.h #define MADV_POPULATE_READ 22 /* populate (prefault) page tables readable */ #define MADV_POPULATE_WRITE 23 /* populate (prefault) page tables writable */
08-02-2024
We tried ::madvise via GLIBC and syscall respectively and wanted to see if the suggested way to tell if the APIs well supported the required function for MADV_POPULATE_WRITE. According to kernel document, "madvise(0, 0, advice) will return zero if advice is supported by the kernel and can be relied on to probe for support". Suppose MADV_POPULATE_WRITE is for 5.14+, and we should not see "return zero" on "Linux 5.4.17-2136.322.6.2.el7uek.x86_64" (See TestTransparentHugePageUsage.log.202402071545) unless all required kernel functions were backported (I guess no). However, even we are having "return zero" which means madvise should function normally, it did not work expectedly when pretouching huge pages. FYI, so far we found the problem is on kernel 5.4.17 and 5.15.0, while it works as expected on 6.2. Oracle CI system: Linux 5.4.17-2136.322.6.2.el7uek.x86_64 (amd64) Linux 5.15.0-105.125.6.2.1.el8uek.aarch64 (aarch64) Github CI, OpenJDK GHA Sanity Checks https://github.com/actions/runner-images/releases/tag/ubuntu22%2F20240201.1 OS Version: 22.04.3 LTS Kernel Version: 6.2.0-1019-azure Image Version: 20240201.1.1 Systemd version: 249.11-0ubuntu3.12
08-02-2024
[~qpzhang] in your patch doesn't using the syscall directly mean you have to check the return value not errno?
08-02-2024
There are three test failures: runtime/os/TestTransparentHugePageUsage.java runtime/os/TestTransparentHugePageUsage.java runtime/Thread/TestAlwaysPreTouchStacks.java I'm attaching the follow log files: -rw-r--r-- 1 dcubed staff 99707 Feb 7 15:45 TestTransparentHugePageUsage.log.202402071543 -rw-r--r-- 1 dcubed staff 99636 Feb 7 15:46 TestTransparentHugePageUsage.log.202402071545 -rw-r--r-- 1 dcubed staff 35308 Feb 7 15:47 TestAlwaysPreTouchStacks.log.202402071546
07-02-2024
[~qpzhang] - I have a Mach5 Tier1 job set running with your changes from 9c70e9384325b44e074a9e8973846343b27fd2cc.
07-02-2024
Then we would have to add more profiling code into the test case in order to collect the information as much as possible. The failure was unable to be reproduced at our local testing system, nor the bundled tests at OpenJDK repo, so we need to understand what configs caused the "AnonHugePages: 0 kB" problem at Oracle CI systems.
07-02-2024
Hi [~dcubed], please help try this https://github.com/limingliu-ampere/jdk/commit/9c70e9384325b44e074a9e8973846343b27fd2cc, we are trying to log more information that could be used to narrow down the issue. Many thanks.
07-02-2024
[~qpzhang] - I'm not able to ssh into any of those machines in order to gather the info that you've requested.
06-02-2024
Hi [~dcubed], Could you please provide the os/kernel/hugepage related information I asked for yesterday? Thanks.
06-02-2024
>> madvise(, , MADV_POPULATE_WRITE) always returns 0even when it is not supported Thanks for the information. So there should be a more appropriate/reliable way to tell if madvise could be used inside os::pd_pretouch_memory other than this: FLAG_SET_DEFAULT(UseMadvPopulateWrite, (::madvise(0, 0, MADV_POPULATE_WRITE) == 0));
05-02-2024
Thanks Daniel, We read the logs and found the number of AnonHugePages at all fields showed 0 unexpectedly. Could you please provide more information about the CI testing system? cat /etc/os-release uname -r grep . /sys/kernel/mm/transparent_hugepage/* grep . /sys/kernel/mm/transparent_hugepage/khugepaged/* In addition, is it a VM instance or bare metal?
05-02-2024
Possibly related: looking at JDK-8325218, and it looks like that madvise(, , MADV_POPULATE_WRITE) always returns 0 ("success") even when it is not supported. E.g. on kernel 5.4 the small test program in the comments in JDK-8325218 returns success (fwiw, madvise also returns 0 for "madvise(0, 0, MADV_POPULATE_WRITE)"; Hence the fallback to use raw writes is not used. Edit: the machine failing the test uses Linux 5.15.0-105.125.6.2.1.el9uek.aarch64 (aarch64), so this is maybe a different issue.
05-02-2024
There are three test failures: runtime/os/TestTransparentHugePageUsage.java runtime/os/TestTransparentHugePageUsage.java runtime/Thread/TestAlwaysPreTouchStacks.java I'm attaching the follow log files: -rw-r--r-- 1 dcubed staff 101148 Feb 2 14:48 TestTransparentHugePageUsage.log.202402021445 -rw-r--r-- 1 dcubed staff 35369 Feb 2 14:49 TestAlwaysPreTouchStacks.log.202402021446 -rw-r--r-- 1 dcubed staff 99244 Feb 2 14:52 TestTransparentHugePageUsage.log.202402021450
02-02-2024
[~qpzhang] - I have a Mach5 Tier1 job set running with your changes from a458eccf04d2d1f46aeb9f09a5c190943812bf2c.
02-02-2024
[~dcubed], Could you please try this new patch https://github.com/limingliu-ampere/jdk/commit/a458eccf04d2d1f46aeb9f09a5c190943812bf2c and collect the generated logs on the Oracle CI test system? Thanks.
01-02-2024
Sorry just now I cancelled a testing request, logging too much information may cause Jtreg fail in another way. Still in progress of updating the test case, thanks for your patience.
31-01-2024
Thanks for the try-out, we found the logging function was incorrectly written and suspected that the newly added MadvPopulateWrite based function in JDK-8315923 might not work properly under your CI system, while the error messages were not captured and printed out as expected. A new patch with more logging will be ready soon for further experiment.
30-01-2024
[~qpzhang] - Sorry runtime/os/TestTransparentHugePageUsage.java still fails on both linux-aarch64 and linux-x64 in Mach5 Tier1: Here's a snippet from the linux-aarch64 log: ----------System.out:(1/2181)---------- Command line: [/opt/mach5/mesos/work_dir/jib-master/install/2024-01-29-1728132.daniel.daugherty.XXXXXXX_for_jdk23.git/linux-aarch64-debug.jdk/jdk-23/fastdebug/bin/java -cp /opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S4011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7f5cab06-90b1-4bfd-af4a-a546a5af956a/runs/25b2f2b7-6aa8-4bd1-8acc-fd5ac7f104d6/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/3/runtime/os/TestTransparentHugePageUsage.d:/opt/mach5/mesos/work_dir/jib-master/install/2024-01-29-1728132.daniel.daugherty.XXXXXXX_for_jdk23.git/src.full/open/test/hotspot/jtreg/runtime/os:/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S4011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7f5cab06-90b1-4bfd-af4a-a546a5af956a/runs/25b2f2b7-6aa8-4bd1-8acc-fd5ac7f104d6/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/3/test/lib:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jtreg.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/junit-platform-console-standalone-1.9.2.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/testng-7.3.0.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jcommander-1.82.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/guice-5.1.0.jar -XX:MaxRAMPercentage=6.25 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-aarch64/jdk-21_linux-aarch64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/0db9c48f-6638-40d0-9a4b-bd9cc7533eb8-S4011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7f5cab06-90b1-4bfd-af4a-a546a5af956a/runs/25b2f2b7-6aa8-4bd1-8acc-fd5ac7f104d6/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/tmp -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch -Xlog:startuptime,pagesize,gc+heap=debug -XX:+UseSerialGC -Xms1G -Xmx1G runtime.os.TestTransparentHugePageUsage$CatSmaps ] ----------System.err:(11/668)---------- java.lang.RuntimeException: The usage of THP is not enough. at runtime.os.TestTransparentHugePageUsage.checkUsage(TestTransparentHugePageUsage.java:102) at runtime.os.TestTransparentHugePageUsage.main(TestTransparentHugePageUsage.java:59) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: The usage of THP is not enough. test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: The usage of THP is not enough. Here's a snippet from the linux-x64 log: ----------System.out:(1/2175)---------- Command line: [/opt/mach5/mesos/work_dir/jib-master/install/2024-01-29-1728132.daniel.daugherty.XXXXXXX_for_jdk23.git/linux-x64-debug.jdk/jdk-23/fastdebug/bin/java -cp /opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S41444/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b5a8ade1-c8a0-422f-aa70-e63516ce464f/runs/863300d7-4226-4bbc-bd2d-fd11a1fa627c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/5/runtime/os/TestTransparentHugePageUsage.d:/opt/mach5/mesos/work_dir/jib-master/install/2024-01-29-1728132.daniel.daugherty.XXXXXXX_for_jdk23.git/src.full/open/test/hotspot/jtreg/runtime/os:/opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S41444/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b5a8ade1-c8a0-422f-aa70-e63516ce464f/runs/863300d7-4226-4bbc-bd2d-fd11a1fa627c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/classes/5/test/lib:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jtreg.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/junit-platform-console-standalone-1.9.2.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/testng-7.3.0.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/jcommander-1.82.jar:/opt/mach5/mesos/work_dir/jib-master/install/jtreg/7.3.1/1/bundles/jtreg-7.3.1+1.zip/jtreg/lib/guice-5.1.0.jar -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/opt/mach5/mesos/work_dir/jib-master/install/jdk/21/35/bundles/linux-x64/jdk-21_linux-x64_bin.tar.gz/jdk-21 -Djava.io.tmpdir=/opt/mach5/mesos/work_dir/slaves/73e57426-9086-438c-bf1c-51bfaf1790ad-S41444/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b5a8ade1-c8a0-422f-aa70-e63516ce464f/runs/863300d7-4226-4bbc-bd2d-fd11a1fa627c/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_runtime/tmp -XX:+UseTransparentHugePages -XX:+AlwaysPreTouch -Xlog:startuptime,pagesize,gc+heap=debug -XX:+UseSerialGC -Xms1G -Xmx1G runtime.os.TestTransparentHugePageUsage$CatSmaps ] ----------System.err:(11/668)---------- java.lang.RuntimeException: The usage of THP is not enough. at runtime.os.TestTransparentHugePageUsage.checkUsage(TestTransparentHugePageUsage.java:102) at runtime.os.TestTransparentHugePageUsage.main(TestTransparentHugePageUsage.java:59) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1575) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: The usage of THP is not enough. test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: The usage of THP is not enough.
29-01-2024
[~qpzhang] - I have a Mach5 Tier1 job set running with your changes from c5b0c4cdf9fa42988faa9fee6ee004ebb599d40a. Will update with results when I get them.
29-01-2024
https://github.com/limingliu-ampere/jdk/commit/c5b0c4cdf9fa42988faa9fee6ee004ebb599d40a please help verify it at the "Oracle CI system (Mach5)".
29-01-2024
Hi [~dcubed], We found the same test passed with the PR#15781, https://github.com/openjdk/jdk/pull/15781/checks?check_run_id=20887574576, https://github.com/limingliu-ampere/jdk/actions/runs/7663433955/job/20886811761, but you showed it failed in Oracle CI system. Probably there are differences between two test systems. Run make test-prebuilt TEST='test/hotspot/jtreg/:tier1_runtime' BOOT_JDK=/home/runner/work/jdk/jdk/bootjdk/jdk JT_HOME=jtreg/installed JDK_IMAGE_DIR=/home/runner/work/jdk/jdk/bundles/jdk/jdk-23/fastdebug SYMBOLS_IMAGE_DIR=/home/runner/work/jdk/jdk/bundles/symbols/jdk-23/fastdebug TEST_IMAGE_DIR=/home/runner/work/jdk/jdk/bundles/tests JTREG='JAVA_OPTIONS=-XX:-CreateCoredumpOnCrash;VERBOSE=fail,error,time;KEYWORDS=!headful' && bash ./.github/scripts/gen-test-summary.sh "$GITHUB_STEP_SUMMARY" "$GITHUB_OUTPUT" Detected target OS, type and env: [linux] [unix] [linux] Running tests using JTREG control variable 'JAVA_OPTIONS=-XX:-CreateCoredumpOnCrash;VERBOSE=fail,error,time;KEYWORDS=!headful' Test selection 'test/hotspot/jtreg/:tier1_runtime', will run: * jtreg:test/hotspot/jtreg:tier1_runtime TEST: runtime/os/TestTransparentHugePageUsage.java build: 0.279 seconds compile: 0.278 seconds driver: 0.345 seconds TEST RESULT: Passed. Execution successful It looks the root cause (major difference) was that the /proc/self/smaps should be completely scanned as the heap address range could be split into more parts, the test case should be updated. We will be proposing a fix soon. However as the auto checks at Github would not be able to verify the update, could you please help test the patch at Oracle CI system in parallel? We will push the PR for review as soon as the fix's effect gets confirmed practically. Thanks in advance.
29-01-2024
We will investigate this issue as a matter of urgency.
29-01-2024
jdk-23+8-499-tier1 finished and the failures only happened on linux-x64-debug and linux-aarch64-debug.
26-01-2024
[~qpzhang] - It looks like your new test is failing in Tier1 in the Oracle CI system (Mach5).
26-01-2024
This is a new test that was added by: JDK-8315923 pretouch_memory by atomic-add-0 fragments huge pages unexpectedly
26-01-2024