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

Daniel D.Daugherty dcubed at openjdk.java.net
Wed Sep 23 20:19:36 UTC 2020


On Wed, 23 Sep 2020 20:15:13 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> 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?

No jni_enter(). Just jni_exit(). We are trying to provoke an unbalanced
monitorexit() here.

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

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


More information about the hotspot-runtime-dev mailing list