On Fri, 3 Dec 2021 05:17:26 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> The issue appears to be due to running jstack before allowing the 4 threads > created by `LingeredAppWithLock` to fully start up and reach their blocking > or timed wait state. With this fix `LingeredAppWithLock.main()` now waits > until the threads have reached the blocking or timed wait state before > calling into `LingeredApp.main()`. > > Tests that use `LingeredAppWithLock` call `LingeredApp.startApp()`, which > will first launch `LingeredAppWithLock` and then block until the lock file is > touched. This blocking/waiting is done the call to `waitAppReady()`, which > will be called before `LingeredApp.startApp()` returns. The lock file is not > touched until `LingeredApp.main()` is called, and it is not called until > after `LingeredAppWithBloc.main()` has already verified the state of all the > threads. Thus by the time `LingeredApp.startApp()` returns, we can be sure > that the threads started by `LingeredAppWithLock.main()` are in the desired > state. This pull request has now been integrated. Changeset: 587e5409 Author: Chris Plummer <cjplum...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/587e5409c2488cf8c3579a4932c588efc5a02749 Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod 8210558: serviceability/sa/TestJhsdbJstackLock.java fails to find '^\s+- waiting to lock <0x[0-9a-f]+> \(a java\.lang\.Class ...' Reviewed-by: kevinw, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/6689
