RFR: 8311177: Switching to interpreter only mode in carrier thread can lead to crashes [v3]

Alex Menkov amenkov at openjdk.org
Sat Jun 1 01:07:11 UTC 2024


On Thu, 30 May 2024 02:41:39 GMT, Serguei Spitsyn <sspitsyn at 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


More information about the serviceability-dev mailing list