nsk.share.TestFailure: Unexpected 0 element of the stack trace: jdk.internal.event.Event.<init>
at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:377)
at nsk.share.Log.complain(Log.java:348)
at nsk.monitoring.stress.thread.strace001.checkElement(strace001.java:258)
at nsk.monitoring.stress.thread.strace001.checkTrace(strace001.java:234)
at nsk.monitoring.stress.thread.strace001.run(strace001.java:106)
at nsk.monitoring.stress.thread.strace001.main(strace001.java:51)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:573)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1576)
[20:19:30.213]
Snapshot of thread: 22
[20:19:30.219] 0: jdk.internal.event.Event.<init>(Event.java:39)
[20:19:30.219] 1: jdk.internal.event.ThreadSleepEvent.<init>(ThreadSleepEvent.java:32)
[20:19:30.219] 2: java.lang.Thread.beforeSleep(Thread.java:461)
[20:19:30.219] 3: java.lang.Thread.sleepNanos(Thread.java:492)
[20:19:30.219] 4: java.lang.Thread.sleep(Thread.java:528)

Interestingly this is not directly caused by JDK-8299419 as the test already allows for this:

"jdk.internal.event.ThreadSleepEvent.<init>"

but not the superclass constructor, which was always a possibility. It is just the timing that has changed again.