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

[Athijegannathan Sundararajan]

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).

Marked as reviewed by sundar (Committer).

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/UpcallStubs.java line 58:

> 56:             }
> 57:         });
> 58:         return new NativeSymbolImpl("", MemoryAddress.ofLong(entry), scope);

Could we use some symbol name for debugging purpose?

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

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