On Fri, 5 Jun 2026 01:53:27 GMT, David Holmes <[email protected]> wrote:
> I think we have "lost the plot" (as the saying goes) with these tests. For > most tests we don't actually care about the exact stacktrace as that is not > what is being tested. For the sleep tests in particular it probably suffices > to check the presence of run() and then sleep() and anything after that is > immaterial. But these old nsk tests are not written in a way that makes it > easy to just make that kind of change. > > Let me mull on this a little. Also maybe @AlanBateman has some ideas. I think the nsk/monitoring/stress tests were developed to test the JSR-174 (JDK 5) implementation. They may have been useful at the time but the tests are a pain to keep working when we change the implementation (as has happened several times recently). test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java is another annoying one. I could imagine re-implementing it where the target thread does a "long sleep", using JVMTI GetThreadState to check for the JVMTI_THREAD_STATE_SLEEPING status, and then asserting that the entry point Thread.sleep frame is in the stack. The test could check the caller frames as they are under control of the test. I would avoid have any dependency on the deeper frames as that is implementation that will change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31357#issuecomment-4628852495
