The current logic for closing memory in panama today is susceptible to live lock if we have a closing thread that wants to close the memory in a loop that keeps failing, and a bunch of accessing threads that want to perform accesses as long as the memory is alive. They can both create impediments for the other.
By using asynchronous handshakes to install an exception onto threads that are in @Scoped memory accesses, we can have close always succeed, and the accessing threads bail out. The idea is that we perform a synchronous handshake first to find threads that are in scoped methods. They might however be in the middle of throwing an exception or something wild like there, where an exception can't be delivered. We install an async handshake that will roll us forward to the first place where we can indeed install exceptions, then we reevaluate if we still need to do that, or if we have unwound out from the scoped method. If we are still inside of it, we ensure an exception is installed so we don't continue executing bytecodes that might access the memory that we have freed. Tested tier 1-5 as well as running test/jdk/java/foreign/TestHandshake.java hundreds of times, which tests this API pretty well. ------------- Commit messages: - 8310644: Make panama memory segment close use async handshakes Changes: https://git.openjdk.org/jdk/pull/16792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310644 Stats: 131 lines in 7 files changed: 59 ins; 25 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/16792.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16792/head:pull/16792 PR: https://git.openjdk.org/jdk/pull/16792
