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

[Coleen Phillimore]

On Wed, 23 Sep 2020 20:16:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> 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?
>
> No jni_enter(). Just jni_exit(). We are trying to provoke an unbalanced
> monitorexit() here.

Yes, it looks like you can break this with JNI code with and extra jni_exit() for the object, and then call the
monitorexit from the interpreter.  This interpreter change is to be consistent with the compiled code that calls via
JRT_LEAF, so compiled code would have the same problem. I can add a fatal to this like: fatal(obj->is_locked(), "Native
code may have unlocked this object"); fatal() would assert in product mode, and errant native code can expect crashes
even in product mode. elem would never be null since it's allocated in the caller.

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

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