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

[Kevin Walls]

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.

Looks good, let's try it!

Was wondering if for the failure in ClhsdbDumpheap.java, the missing text was too far from when LingeredApp was started.  But if it's the first subtest, then it's the stacks in a dumpheap output where we don't find the required steadyState text.  So the test only has to create the array of subtests and call the first one, before the LingeredApp thread has really blocked...

Good to make this harmless test change so we get long term testing of it.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19951#pullrequestreview-2150892788