RFR: 8269881: SA stack dump fails to include stack trace for SteadyStateThread

[Serguei Spitsyn]

On Fri, 28 Jun 2024 20:34:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The completely unrelated fix to [JDK-8335124](https://bugs.openjdk.org/browse/JDK-8335124) led me to believe that the issue with sometimes not being able to get the stack trace of the SteadyStateThread might be due to the thread being active for a short period after being reported as in the Thread.State.BLOCKED state. Once set to that state, the thread still needs to call a native OS API to block the thread so it is truly idle. During this time the thread stack might be inconsistent and not walk-able. The fix is to add a short sleep after the thread has moved to the Thread.State.BLOCKED state to give it a chance to finish blocking.
> 
> Tested with Tier1 CI and all svc test tasks for tier2 and tier5.

This is the most simple solution but not 100% reliable.
Looks okay to me.

test/lib/jdk/test/lib/apps/LingeredApp.java line 589:

> 587:         }
> 588: 
> 589:         // Wait a short period of time so we can be sure the thread truly is blocked. See JDK-8269881.

Nit: Would this be better?:
  "truly is blocked" => "is truly blocked"

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2155294863
PR Review Comment: https://git.openjdk.org/jdk/pull/19951#discussion_r1663448562