RFR: 8309408: Thread.sleep cleanup

[Alan Bateman]

On Mon, 5 Jun 2023 20:05:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following commit in loom heavily modified this file with a lot of added expected methods. There are other related tests with similar changes. I'm not so sure I understand the need for so many additions, and also why expectedLength is so out of sync with the number of added method. I don't believe this commit was reviewed individually, but was just part of the overall loom review when merge into jdk. Perhaps it should be revisited.

These tests aren't easy to read or maintain, it would be good to re-visit them. In some cases, the tests capture the stack trace asynchronously so the test needs to know about all code paths.

As regards ThreadController, used by the nsk/monitoring/stress/thread/straceXXX tests, the main thread waits at a barrier (a CountDownLatch) until all sleeping threads are ready to sleep. Once the main thread is released, it checks all the sleepers are in TIMED_WAITING state and samples their stack traces with the ThreadMXBean and related APIs. The test fails if there are frames corresponding to methods that the test doesn't know about. If a thread is sleeping then we shouldn't see frames for beforeSleep/afterSlee. My reading of these tests is that the main thread could poll a SleepingThread after it counts down and before it parks in sleep. It's doing an expensive ThreadMXBean::getAllThreadIds once released and that may explain why it hasn't been seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14303#discussion_r1219348675