As discussed in JBS the deadlock occurs when the call to `ReleasePrimitiveArrayCritical` performs the transition from native to VM, and in the process checks for special runtime exit conditions - which includes the `obj_deopt_suspend` request. The simple solution is to define a custom JNI ENTRY with custom `ThreadInVMfromNative` that elides the exit check.
The change is limited to `ReleasePrimitiveArrayCritical` and `ReleaseStringCritical`. There is no regression test as this has only been seen in long running stress tests. Testing: -tiers 1-6 ------------- Commit messages: - 8369515 Changes: https://git.openjdk.org/jdk/pull/28779/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28779&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369515 Stats: 31 lines in 2 files changed: 27 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28779.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28779/head:pull/28779 PR: https://git.openjdk.org/jdk/pull/28779
