JDK-8366893 : java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 21,25,26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-09-04
  • Updated: 2025-11-24
  • Resolved: 2025-09-05
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 21 JDK 25 JDK 26
21.0.10Fixed 25.0.2Fixed 26 b15Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
GetStackTraceALotWhenPinned test times out every so often in GHA.

The last sightings are on macos-aarch64:

2025-09-04T10:41:29.357879Z => 87894 of 100000
2025-09-04T10:41:30.365534Z => 88105 of 100000
Timeout signalled after 300 seconds
2025-09-04T10:41:31.367068Z => 88298 of 100000
2025-09-04T10:41:32.377128Z => 88400 of 100000

2025-09-03T10:08:37.713537Z => 74715 of 100000
2025-09-03T10:08:38.717750Z => 74818 of 100000
Timeout signalled after 300 seconds
2025-09-03T10:08:39.722960Z => 74922 of 100000
2025-09-03T10:08:40.726642Z => 75024 of 100000

Looks like we are nearly there, just need fewer iterations. I think like with JDK-8344577, we just need to extend the test check for AArch64 macs as well. 
Comments
[jdk21u-fix-request] Approval Request from Roland Mesde for backport of JDK-8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64. Ran the related tests on macos-aarch64: (Passed) - make test TEST=java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java 2>&1 | tee macos-aarch64-specific-1-test.log (Passed) - make test TEST=java/lang/Thread/virtual/stress/ParkALot.java 2>&1 | tee macos-aarch64-specific-2-test.log Results are attached. [macos-aarch64-specific-1-test.log](https://github.com/user-attachments/files/23637990/macos-aarch64-specific-1-test.log) [macos-aarch64-specific-2-test.log](https://github.com/user-attachments/files/23637991/macos-aarch64-specific-2-test.log)
19-11-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/2484 Date: 2025-11-19 19:07:21 +0000
19-11-2025

[jdk25u-fix-request] Approval Request from sendaoYan Clean backport to fix test bug which may cause test timed out on macos-aarch64. Change has been verified locally on linux-x64 and linux-aarch64. I do not have macos-aarch64 machine. Test-fix only, I think it's no risk.
25-09-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk25u/pull/184 Date: 2025-09-11 11:26:38 +0000
11-09-2025

Changeset: 0dad3f1a Branch: master Author: Aleksey Shipilev <shade@openjdk.org> Date: 2025-09-05 10:55:41 +0000 URL: https://git.openjdk.org/jdk/commit/0dad3f1ae8d0c35c4b7a8188ad7854d01c7cd6b4
05-09-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/27104 Date: 2025-09-04 15:47:33 +0000
04-09-2025

I suspect the issue is that the tests in this directory are completing for CPU cycles when run concurrently (we moved away from using exclusivedirs for the tests in this directory as it slowed down the jdk:tier1 runs. The reason for several GetStackTraceALotXXX tests is that this is code that needs to be bashed due to the retry in the implementation. There is work in progress that may generalize the virtual thread handshake support so it can be used beyond JVMTI, which will allow us to replace the Thread::getStackTrace and significantly reduce the need for these stress tests. In the mean-time, then it's okay to reduce the iterations on macOS to workaround the slowest on these GHA machines.
04-09-2025

Mind if I PR the fix on top of JDK-8344577 that would hopefully make the "lucky" runs even more lucky? The instances I saw so far look to just need a bit more time.
04-09-2025

See also JDK-8366669 where we are trying to establish what GHA is using.
04-09-2025