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

[Maurizio Cimadamore]

On Tue, 5 Oct 2021 11:45:45 GMT, Jorn Vernee <jvernee 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).
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeSymbol.java line 46:
> 
>> 44:      * Restricted methods are unsafe, and, if used incorrectly, their use might crash
>> 45:      * the JVM or, worse, silently result in memory corruption. Thus, clients should refrain from depending on
>> 46:      * restricted methods, and use safe and supported functionalities, where possible.
> 
> Why is this restricted?

because you can create a native symbol out of an arbitrary address (e.g. MemoryAddress.ofLong), which then, if passed to a downcall method handle, will cause havocs. That said, true that, at the moment you can pass Addressable to a downcall method handle - but maybe that's the issue? E.g. downcall method handle needs to take in a NativeSymbol? That way, all native symbols created by our APIs are known to be safe (upcall and symbol lookup) - but the user is still free to create custom symbols - although these latter would be restricted. Makes sense?

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

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