RFR: 8345543: Test serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java failed: expected JVMTI_ERROR_OPAQUE_FRAME instead of: 0 [v2]

[Serguei Spitsyn]

On Thu, 16 Jan 2025 02:04:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I do not think this change is correct. While it may fix the issue with the virtual thread it now changes the behaviour for regular threads. For a very long time we have done the following in order:

JavaThreadBlockedOnMonitorEnterState jtbmes(current, this);`
current->set_current_pending_monitor(this);`
DTRACE_MONITOR_PROBE(contended__enter, this, object(), current);
if (JvmtiExport::should_post_monitor_contended_enter()) {
  JvmtiExport::post_monitor_contended_enter(current, this);

> and it all works correctly for regular threads. If you delay setting the thread state that may cause problems elsewhere. This also makes me wonder whether the rest of the above actions are necessarily correct in the virtual thread case.

Both JVMTI and DTRACE probes should not depend on the target thread to be in BLOCKED state. Moreover, JVMTI spec is clear that the event is posted when the target thread `is about to wait on` or `is attempting to enter` a monitor. I can move this line after a `JavaThreadBlockedOnMonitorEnterState` object is defined:

    current->set_current_pending_monitor(this);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23125#issuecomment-2594429815