Review Request JDK-8240975: Extend NativeLibraries to support explicit unloading

[Alan Bateman]

On 13/03/2020 18:16, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8240975/webrev.00/
>
> This is a follow-up task for Panama to allow explicit unloading of 
> native library after JDK-8228336.  `NativeLibraries` associated with a 
> class loader has the capability to auto unload native libraries when 
> the class loader is reclaimed.  This adds a new 
> `NativeLibraries::unload` method that provides the ability to unload a 
> native library on request.  This only allows `NativeLibraries` of no 
> relationship with a class loader where auto unloading is disabled
The difference between the 2 constructors might not be obvious at the 
use sites. I'm just wondering if would be better to use static factory 
methods instead, e.g. the 2-arg constructor could be replaced with a 
trusted(caller, searchLibPath) method that would make it a lot more 
obvious in the places where that will eventually be used.

A small inconsistency is that VM.isSystemDomainLoader is used in 
constructor whereas the other checks for null and platform class loader 
(plus app class loader).

The Main test could use Path.of("classes"). In setup, dir could be a 
Path and also Path p = Files.createDirectories(...) would allow the 
Files.move to be a bit more readable. I can't quite tell why the test is 
skipped with -Xcomp but maybe it's just too slow and times out?

A small suggestion for NativeLibrariesTest is that loadWithCustomLoader 
might be a better name to load p.Test with a custom loader. Also noticed 
libnativeLibrariesTest.c has a 2017 date on it.

-Alan.