On Fri, 3 Jul 2026 04:05:15 GMT, Patricio Chilano Mateo <[email protected]> wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001.java line 51: >> >>> 49: * @library /vmTestbase >>> 50: * /test/lib >>> 51: * @requires test.thread.factory == null >> >> Can you elaborate on the need for this? I don't see any mach5 failures of >> this test for almost a year. > > The monitorenter VM call is `JRT_ENTRY_NO_ASYNC`, meaning we don’t process > asynchronous exceptions on the way back to Java. This patch restricts > installing asynchronous exceptions for virtual threads blocked there as we > cannot guarantee when they will be thrown. This test is exercising that case > so returning `JVMTI_ERROR_OPAQUE_FRAME` makes it fail. So even though this case has not been observed to fail we are now making it fail "just in case"? That seems wrong. I would consider it a perfectly legitimate debugging scenario to have a thread blocked on monitor entry, suspend it (as required) and call `StopThread` on it, and expect it to work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31759#discussion_r3517599951
