On Thu, 30 May 2024 02:41:39 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp >> line 201: >> >>> 199: >>> 200: // need to reset this value after the breakpoint_hit1 >>> 201: received_method_exit_event = JNI_FALSE; >> >> There was a loom-dev email thread regarding this last year. Seems related. I >> had concluded that the way the test was written that no MethodExit event >> should have been received. I'm not sure if I missed something in my analysis >> or if this failure is a result of your changes: >> >> https://mail.openjdk.org/pipermail/loom-dev/2023-August/006059.html >> https://mail.openjdk.org/pipermail/loom-dev/2023-September/006170.html > > Thank you for the comment and links to the discussion. In fact, I've observed > the MethodExit events really posted between the breakpoint hits: `hit1` and > `hit2`. The first one is at the return from the `unmount()` method. I was not > able to prove why they should not be expected. I'm not sure I follow the test logic. Its summary says "Verifies that MethodExit events are delivered on both carrier and virtual threads", but now it just ignores MethodExit requested for carrier thread in breakpoint_hit1. Then there is no sense to request the event on carrier thread. Per the test summary I'd expect the test should test MethodExit for carrier thread, but then java part needs to force unmount ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19438#discussion_r1623073345
