> 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.
Erik Österlund has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #3 from JornVernee/PR_async_close+NoToNativeTrans - don't transition to native state on Unsafe_CopySwapMemory0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16792/files - new: https://git.openjdk.org/jdk/pull/16792/files/0b91ac9a..83cef378 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16792&range=03-04 Stats: 35 lines in 1 file changed: 9 ins; 18 del; 8 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
