On Fri, 5 Jun 2026 06:31:47 GMT, Alan Bateman <[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. Thanks Alan and David.. what I found is test already does the long-sleep part: SleepingThread.bringState() does a single Thread.sleep(3600*1000) that gets interrupted at teardown, and checkThreadInfo reads both state and stack from the same ThreadInfo snapshot, so there’s no race between the state check and the stack fetch. So what Im thinking is since the remaining gap is really just the frame checking.. I’ll rework the patch to positively assert that the java.lang.Thread.sleep entry frame is present in the stack, instead of accepting any java/jdk/sun frame like the current patch does, agreed that was too permissive. the test-controlled caller frames (run, bringState, recursion chain) are already verified through the existing expectedMethods checks, so those stay. everything above the sleep entry point just gets ignored, no JDK method names hardcoded anywhere. Also correct me if Im wrong.. I've one question though on JVMTI GetThreadState since these are java.lang.management tests, so that would mean adding a native agent to them. Moreover ThreadInfo already gives state and stack from one consistent snapshot, checking TIMED_WAITING plus the sleep frame seems equivalent at this level. is that sufficient or would you still want the JVMTI confirmation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/31357#issuecomment-4665314646
