P4
In a work on the JDK-8345543 fix it was discovered that the MonitorContendedEnter events are posted after the target thread changed its state to BLOCKED. This is not correct and has to be fixed. Also, JVMTI spec may need an update to clarify this.
There was also the following suggestion from Alan:
"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."
There was also the following suggestion from Alan:
"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."