On Thu, 18 Dec 2025 01:21:17 GMT, David Holmes <[email protected]> wrote:
>> 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`. >> >> UPDATE: we are now employing a much simpler solution. >> >> There is no regression test as this has only been seen in long running >> stress tests. >> >> Testing: >> -tiers 1-6 > > David Holmes has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Greatly simplifed fix to just defer object_deopt whilst in JNI critical > region > - Merge branch 'master' into 8369515-jni-critical > - Revert "8369515" > > This reverts commit 3beb23ccbf5adb98d8c6ad404d40c603bbf499dc. > - 8369515 Fixing deadlock issues caused by suspend requests can easily become quite messy, but not this time. I think it's an elegant solution, with a good explaining source code comment. Thank you! ------------- Marked as reviewed by fbredberg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28779#pullrequestreview-3591638468
