On Fri, 24 Nov 2023 18:30:17 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
>> 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 I don't know about the Panama details but the asynchronous handshake usage looks good. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16792#pullrequestreview-1753119472
