[foreign-memaccess+abi] RFR: Investigate alternate strategy to acquire resource scopes [v2]
Chris Hegarty
chegar at openjdk.java.net
Tue Apr 20 15:49:14 UTC 2021
On Tue, 20 Apr 2021 14:31:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> The code in this PR demonstrates a possible, alternate approach to resource scope acquire.
>>
>> Instead of having `ResourceScope.Handle` be `AutoCloseable` (which is problematic, given that `javac` issues warning when an auto closeable is not used inside the body of the try block) this patch adds a new method on resource scopes, namely `ResourceScope::release(Handle)`.
>>
>> The semantics of this method is similar to the previous `Handle::close` - one thing that is different is how implicit scopes are handled - instead of trying to keep the implicit scope alive through the handle instance, here we simply return a "dummy" handle, which does nothing.
>>
>> The idea is that if you write idiomatic code like:
>>
>>
>> var handle = scope.acquire();
>> try {
>> // critical region
>> } finally {
>> scope.release(handle);
>> }
>>
>>
>> This will work for both explicit scopes (since acquiring actively prevents calls to `ResourceScope::close`) - but also for implicit scopes, since the `release` call inside the finally block will effectively require the scope to be reachable at this stage (see reachability fence inside `ResourceScopeImpl::release`).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>
> Add reachability fence on ResourceScope::release
I like this change, and the idiom that it promotes. I use similar in experiments that I've been doing, and it works well.
There is one small wart that we can probably live it, but I'd like to ensure that we're comfortable with it - Handle::close returning the global scope for "The implicit resource scope handle" (I like this term). It seems odd at first that the scope method would not return the actual implicit scope, but I understand the reasoning for it - and I accept that the handle is kinda logically meaningless, but exists to help promote good usage patterns.
-------------
PR: https://git.openjdk.java.net/panama-foreign/pull/511
More information about the panama-dev
mailing list