Review Request JDK-8164512: Replace ClassLoader use of finalizer with phantom reference to unload native library

Kim Barrett kim.barrett at oracle.com
Tue Sep 26 21:20:19 UTC 2017


> On Sep 26, 2017, at 1:27 PM, mandy chung <mandy.chung at oracle.com> wrote:
> On 9/25/17 11:37 PM, Kim Barrett wrote:
>> src/java.base/share/classes/java/lang/ClassLoader.java
>> 2394         public void register() {
>>                  [...]
>> 2406                 // register the class loader for cleanup when unloaded
>> 2407                 if (loader != getBuiltinPlatformClassLoader() &&
>> 2408                     loader != getBuiltinAppClassLoader()) {
>> 2409                     CleanerFactory.cleaner()
>> 2410                         .register(loader, new Unloader(name, handle, isBuiltin));
>> 2411                 }
>> 
>> Can anything before the cleanup registration throw?
> 
> No within the register method.

I think there are some opportunities for OOME, but I think no worse than before.
And the result would be a loaded library without the unload registration, which
seems like it might perhaps be annoying but probably not fatal.

> I'm considering to separate the JNI_FindClass change to target 18.3 and provide a flag to restore the current behavior so that it may help existing code to identify its dependency on the current behavior and give time to migrate.  Then target the finalizer to Cleaner change in 18.9.
> 
> It's unknown to us how many existing native libraries are impacted by this change (calling FindClass from JNI_OnUnload to load classes visible the class loader being unloaded).   I suspect it's rare. If FindClass is called when the native library is being unloaded and fail to find the class due to this change, it is not hard to find out but the code might crash if it does not handle the class not found case properly.
> 
> Any opinion?

I’m in favor of removing this finalizer sooner rather than later, but you probably could have guessed that.



More information about the core-libs-dev mailing list