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.
