RFR: 8345543: Test serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java failed: expected JVMTI_ERROR_OPAQUE_FRAME instead of: 0 [v4]
Serguei Spitsyn
sspitsyn at openjdk.org
Fri Jan 17 08:31:39 UTC 2025
On Fri, 17 Jan 2025 07:14:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> I don't have an opinion on the sequencing but it is clear that there is some technical debt here, and kinda surprising that the issue of thread states when invoking JVMTI callbacks hasn't caused problems already. It may be useful to create a test case that upcalls to Java code in the live phase from all JVMTI callbacks that have a JNIEnv parameter. If done in the blocked state it would be interesting to see how far it gets before tripping up on an assert or guarantee. It's possible that such an experiment will identity cases where the spec should warn not to do this.
I'm not sure I clearly understand your idea about all JVMTI callbacks that have a JNIEnv parameter. But it makes sense to do this in a `MonitorContendedEnter` callback.
I've filed two new bugs:
[8347979](https://bugs.openjdk.org/browse/JDK-8347979) MonitorContendedEnter should not be posted in BLOCKED state
[8347980](http://0.127.97.76/) The JVMTI events should not be posted for ObjectLocker
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23125#issuecomment-2597689914
More information about the hotspot-runtime-dev
mailing list