[foreign-memaccess+abi] RFR: 8274602: Generalize UpcallStub into NativeSymbol

Maurizio Cimadamore mcimadamore at openjdk.java.net
Tue Oct 5 14:34:56 UTC 2021


On Thu, 30 Sep 2021 15:12:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> It might sometimes be useful to define a custom symbol lookup which returns symbols backed by a library that can be unloaded dynamically (e.g. using dlopen).
> We indeed have all the pieces to get there, except that symbnol lookup returns a memory address, which is not a scoped entity.
> 
> To address this, I propose that we add a new sealed interface/final class (`NativeSymbol`) which implements `Addressable` and is used in two places:
> * as a return value for a symbol lookup
> * as a proxy for an upcall stub
> 
> In other words, `NativeSymbol` is used to reference to some symbol in some library, where the library can have a given scope. Upcall stubs are just a special case where the upcall symbol is synthetized on the fly by the VM. With this in place, I think we can drop `CLinker.UpcallStub` and just use an "anonymous` NativeSymbol to represent upcall stubs.
> 
> With this, it should be possible to define a dlopen-based lookup such as the one below:
> https://github.com/sundararajana/panama-jextract-samples/blob/master/dlopen/Dlopen.java
> 
> In a way that is completely *safe* - that is, so that it is not possible for a library to be unloaded while a function is being executed (even when the scope  associated to the native symbol is shared).

I've tweaked the API so that downcallHandle now accepts a `NativeSymbol` - which is what I should have done all along. Now all symbols generated by the API are safe - but the ones constructed by users are not (as they are backed by "random" addresses) - so I think it's fair to mark the symbol factory as restricted. With these API changes, we also gain a bit of robustness, as a `VaList` can no longer be passed "as is" as a target address to a downcall method handle. Sure, the user can still create a native symbol which contains the very valist address - but that seems more convoluted (and restricted).

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/589


More information about the panama-dev mailing list