[foreign] RFR 8215553: Remove SystemABI::freeUpcallStub

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Dec 18 13:14:35 UTC 2018


Forgot to add: I tested the patch by running all tests multiple times 
(esp. the heavy TestUpcall :-)) and adding println statements when the 
cleaner was called, to make sure that the logic was indeed running when 
executing long-lived tests.

Maurizio

On 18/12/2018 13:12, Maurizio Cimadamore wrote:
> Hi,
> few months ago we moved to a new model for managing lifecycle of 
> callbacks, where callbacks were explicitly allocated through a Scope; 
> when the scope is closed, all callbacks registered onto that scope are 
> freed.
>
> Back then, I failed to realize that we don't really need an API point 
> to free the callback - we can just rely on a Cleaner to do its job 
> when the callback is no longer referenced from Java code. Since a 
> callback will always be stored in some scope (when active), this will 
> effectively prevent it from being collected.
>
> Note: this model is very different from what we had before, where 
> callbacks were NOT allocated using a Scope, but only implicitly by 
> passing lambdas to functions. In that case, using a Cleaner was bad, 
> as it  sometimes led to GC happening _in the middle_ of a function 
> call. This can no longer happen, as a Scope will now hold tight on the 
> callbacks used at any given point in time.
>
> Of course, users of the low-level SystemABI, must pay extra care: as 
> soon as an upcall symbol goes out of scope, it is ready for 
> collection; that means that if a client of SystemABI wants an upcall 
> symbol to remain alive, it has to stash it somewhere. Given the 
> audience of this SystemABI API, I think this is an acceptable 
> compromise (and one I've seen elsewhere, e.g. JNR). On the plus side, 
> the API got tighter, as we no longer need a 'free' method.
>
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/panama/8215553/
>
> Cheers
> Maurizio
>


More information about the panama-dev mailing list