[foreign-memaccess+abi] RFR: 8266814: Improve library loading with SymbolLookup abstraction

[Maurizio Cimadamore]

On Mon, 10 May 2021 14:05:53 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> This patch implements the library loading abstraction described in:
>> 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-May/013684.html
>> 
>> That is, a functional interface called `SymbolLookup`, and a couple of factories to get a lookup for a given classloader, and to get a *system* lookup, useful to lookup C symbols.
>> 
>> To implement the system lookup, we load `msvcrt.dll` on Windows, while we build and load an empty library (which depends on libc) on Mac/Linux. This approach is better than relying on RTLD_DEFAULT (which can sometimes leak symbols from libraries loaded independently). Also, doing this bypasses the problem of figuring out the location of libc, which, on Linux system is particularly gnarly, because of the multi-arch support.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SymbolLookup.java line 85:
> 
>> 83:     static SymbolLookup loaderLookup(ClassLoader loader) {
>> 84:         Reflection.ensureNativeAccess(Reflection.getCallerClass());
>> 85:         Objects.requireNonNull(loader);
> 
> why do we filter null (bootstrap) loader?

Because boot loader is under control of the JDK, not the user. I don't think it's desirable to introduce coupling between user code and set of libraries which happen to be loaded by boot loader.

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

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