JDK-8334513 : New test gc/TestAlwaysPreTouchBehavior.java is failing on MacOS aarch64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 24
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2024-06-19
  • Updated: 2025-06-10
  • Resolved: 2025-05-24
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 25
25 b25Fixed
Related Reports
Relates :  
JDK-8334570 - Problem list gc/TestAlwaysPreTouchBehavior.java
Relates :  
JDK-8333769 - Pretouching tests dont test pretouching
Relates :  
JDK-8357570 - [macOS] os::Bsd::available_memory() might return too low values
Relates :  
JDK-8359104 - gc/TestAlwaysPreTouchBehavior.java# fails on Linux
Sub Tasks
JDK-8334570 :  
Problem list gc/TestAlwaysPreTouchBehavior.java - Resolved
Description
Test added by JDK-8333769

gc/TestAlwaysPreTouchBehavior.java#ParallelCollector
gc/TestAlwaysPreTouchBehavior.java#ZSinglegen

Unfortunately test logs are missing. The basic error was:

java.lang.RuntimeException*RSS*of*this*process*...b*should*be*bigger*than*or*equal*to*committed*heap*mem*...b*expected*...*...

Edit: Also gc/TestAlwaysPreTouchBehavior.java#G1

java.lang.RuntimeException: RSS of this process(60014592b) should be bigger than or equal to committed heap mem(536870912b): expected 60014592 > 536870912
	at jdk.test.lib.Asserts.fail(Asserts.java:691)
	at jdk.test.lib.Asserts.assertGreaterThan(Asserts.java:400)
	at gc.TestAlwaysPreTouchBehavior.main(TestAlwaysPreTouchBehavior.java:127)
	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.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1575)
Comments
Thanks! Maybe the problem on some PPC64 machines is the same as JDK-8357570 (or similar)?
02-06-2025
[~mdoerr] I sent you a mail.
27-05-2025
The test is still failing on linuxppc64le: RSS of this process(268435456b) should be bigger than or equal to heap size(268435456b) (available memory: 115513753600): expected 268435456 > 268435456
26-05-2025
Changeset: e8933057 Branch: master Author: Thomas Stuefe <stuefe@openjdk.org> Date: 2025-05-24 09:51:53 +0000 URL: https://git.openjdk.org/jdk/commit/e89330579d5f38e282512211711fffeeea3e899e
24-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25384 Date: 2025-05-22 07:41:28 +0000
22-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/19803 Date: 2024-06-20 11:35:06 +0000
09-07-2024
[~stefank] yes, that is expected. I skip the test if I believe there is not enough memory.
21-06-2024
With your patch my way of reproducing the issues results in: ``` available: 1463255040(required 1610612736) jtreg.SkippedException: Not enough memory for this test (1463255040) at gc.TestAlwaysPreTouchBehavior.main(TestAlwaysPreTouchBehavior.java:165) 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.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1575) ``` I guess that's good?
20-06-2024
I have a preliminary patch. [~dholmes][~stefank][~mdoerr] could you please test this: https://github.com/openjdk/jdk/pull/19803 If this still fails for MacOS (still cannot reproduce), I will exclude MacOS for now.
20-06-2024
The CPU and OS were correctly set when the bug was filed.
20-06-2024
The failure with text: RSS of this process(60014592b) should be bigger than or equal to committed heap mem(536870912b): expected 60014592 > 536870912 Was running on 'Mac OS X 12.6.2 (aarch64)' with: processors:8 maxMemory:17179869184 maxSwap:20401094656]
19-06-2024
[~mdoerr] could you attach the jtr file? Was this a debug jvm? Was the machine swapping? The PPC issue feels like its an underprovisioned machine, and some of the touched pages got swapped out since touching. The MacOS issue (at least I assume it was MacOS) in the issue description is weird. RSS is just 60MB, only. That is strangely very close to the RSS a normal release JVM would have with -AlwayPreTouch. So, on MacOS we may see AlwaysPreTouch not working at all. (Hence my question about UEK. The 60MB would be explainable if we did not run on MacOS but on Oracle Linux on an UEK kernel, where pretouching did not workl) It is also very weird that the old version of this test (which only ran for release builds, only Linux, only Parallel) did not show any errors at SAP. That test used a much larger heap size of 1G. So, if the machine had been underprovisioned then, I would expect errors not to appear the moment we change the test and shrink the heap size.
19-06-2024
Also observed "RSS of this process(535691264b) should be bigger than or equal to committed heap mem(536870912b): expected 535691264 > 536870912" in gc/TestAlwaysPreTouchBehavior.java#G1 on ppc64le.
19-06-2024
Okay, I'll take a look
19-06-2024
This happens on MacOS AArch64.
19-06-2024
[~dholmes] What platform did these problems occur on?
19-06-2024
I cannot reproduce the problem on my Macbook. There is an unrelated issue on all platforms with Parallel and ZapUnusedHeapArea in debug builds (what Alfred brought up), but this is not what we see here. Are you really *sure* its MacOS aarch? Not, e.g. Oracle Linux with their broken UEK and the MADV_POPULATE flag issue? Because on my Mac m1 everything works. Log files would be good, and clear information which builds and which platforms are affected. Update: I missed your report, Stefan. Yes, maybe thats it. Curious though, because the linux-only test before worked. If that is the issue, this means that Mac aarch tests are running on undersized machines?
19-06-2024
FWIW, I managed to reproduce the problem by running multiple instance of the test at the same time. I guess that if the OS runs out of memory, then we might not get as high RSS as we expect?
19-06-2024