RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function

[Patricio Chilano Mateo]

On Wed, 23 Sep 2020 18:41:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> But JNI MonitorExit() calls ObjectSynchronizer::jni_exit() instead and that calls check_owner() which will throw
>> java_lang_IllegalMonitorStateException() if the thread is not the owner. I agree we might still need to throw
>> java_lang_IllegalMonitorStateException() here for the release bits though. Maybe we still need to cover the case of the
>> classfile having wrong bytecodes and there is an extra monitorexit?
>
> The JNI MonitorExit() call will succeed because the calling thread is
> the owner of the monitor. The subsequent monitorexit byte code
> should fail because the calling thread is no longer the owner of
> the monitor. It's a way of simulating an errant situation.

Ok, so the scenario would be:
1) Thread calls monitorenter bytecode
2) Thread calls jni_enter() * n and jni_exit() * (n+1) (extra unlock). Also with JNI we always inflate the lock.
3a) If no deflation happens and the thread calls monitorexit bytecode then we hit the assert in
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/objectMonitor.cpp#L1047 3b) If the monitor was
deflated then on monitorexit is_unlocked() returns true and we throw java_lang_IllegalMonitorStateException. (We would
change this case then).

Is that correct?

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

PR: https://git.openjdk.java.net/jdk/pull/320