JDK-8370578 : SystemMapTest.java#normal fails intermittendly on macOS aarch64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 25,26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2025-10-24
  • Updated: 2025-11-11
  • Resolved: 2025-11-03
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 26
26 b23Fixed
Related Reports
Relates :  
Description
Test serviceability/dcmd/vm/SystemMapTest.java#normal failed today on macOS aarch64 (usually it works however).
The test machine has macOS 14.5,  CPU  Apple M2 Ultra , the test was executed as part of the whole :tier1 jtreg tests.

In the log we find :

0x000102cec000-0x000102cf4000 32768 rw-/rwx shr 0 INTERN /private/var/folders/ps/6ym_x8gd6qz72g9288px78pc0003kp/T/hsperfdata_jvmtests/28134

but the regex is :

java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\\-rwx]*/[\\-rwx]* +pvt +(0x\\p{XDigit}+|\\d+) +.*/.*/hsperfdata_.*' missing from stdout/stderr
                at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
                at SystemMapTest.run(SystemMapTest.java:67)
                at SystemMapTest.jmx(SystemMapTest.java:78)
                at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
                at java.base/java.lang.reflect.Method.invoke(Method.java:565)
                at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
                at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
                at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
                at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
                at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
                at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
                at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
                at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
                at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)

Seems the test expects "pvt" but gets "shr" in the output - any idea? Should we handle "shr" too in the test ?
Comments
Changeset: 05efc1fa Branch: master Author: Simon Tooke <stooke@openjdk.org> Committer: SendaoYan <syan@openjdk.org> Date: 2025-11-03 02:20:17 +0000 URL: https://git.openjdk.org/jdk/commit/05efc1fa991c3fd895bf2f7c7d9e7916692b98e6
03-11-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28025 Date: 2025-10-28 20:28:10 +0000
29-10-2025

PR created: https://github.com/openjdk/jdk/pull/28025
28-10-2025

I've just looked into this and found it can be either. I will create a PR to update the tests accordingly, and then look to see what the underlying cause might be. Running on an M1, it's seen as mapped private in the test suite jtr file, while performing System.map on a tiny Sleep() loop shows me it's mapped shared: openjdk % grep hsperf ./jtreg/work/serviceability/dcmd/vm/SystemMapTest_*.jtr ./jtreg/work/serviceability/dcmd/vm/SystemMapTest_normal.jtr:0x000104c7c000-0x000104c84000 32768 rw-/rwx pvt 0 ./jtreg/work/serviceability/dcmd/vm/SystemMapTest_zgc.jtr:0x000100994000-0x00010099c000 32768 rw-/rwx pvt 0 /private/var/folders/fd/wn9cs7kj1zj2_jqrlj_20s_80000gn/T/hsperfdata_simont/52945 openjdk % openjdk % ./jdk/build/macos-aarch64-release-shenandoah/jdk/bin/jcmd Sleep System.map | grep hs 0x000104d8c000-0x000104d94000 32768 rw-/rwx shr 0x1d4000 /private/var/folders/fd/wn9cs7kj1zj2_jqrlj_20s_80000gn/T/hsperfdata_simont/52560 openjdk %
27-10-2025

Drive-by comment: Interesting that it shows "private" at all. I would have expected the hsperfdata shared segment to be "SHR" since I assume it would not opened as an anonymous mapping, but as a shared mapping over a file - after all, this segment gets read by outside processes, or?
24-10-2025