RFR: 8366893: java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on macos-aarch64

[Alan Bateman]

On Thu, 4 Sep 2025 15:47:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 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](https://bugs.openjdk.org/browse/JDK-8344577), we just need to extend the test check for AArch64 macs as well.
> 
> Additional testing:
>  - [x] MacOS AArch64 server fastdebug, `java/lang/Thread/virtual/stress`, 10x

Marked as reviewed by alanb (Reviewer).

It looks like GH is using a fleet of Reliant Robins as the runners for macOS arm64.  Do you know what value of JTREG_JOBS is used for jtreg --concurrency on these apparently 3-core VMs?  If concurrency is >1 then I assume we have more than one stress test running concurrently.

(The change are okay of course. Right now, the TL handshake for virtual threads is limited to JVMTI usages but that make change, in which case we can re-visit Thread::getStackTrace and avoid the retry during transitions, and reduce the need for the GetStackTraceALotXXX stress tests).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27104#pullrequestreview-3188437905
PR Comment: https://git.openjdk.org/jdk/pull/27104#issuecomment-3257482804