You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Jaroslav Tulach <ja...@gmail.com> on 2021/04/09 12:21:50 UTC
Memory leak was: Manipulating System Classpath with NetBeans (OpenJFX assumes classes can be loaded by FindClass)
> Hi,
>
> JNI_OnLoad has a companion JNI_OnUnload [1], which is the perfect place
> to invoke an env->DeleteGlobalRef(MyWhateverClass), allowing the JVM
> garbage collector to do a proper cleanup.
That method is called "when the class loader containing the native library is
garbage collected." However the class loader cannot be GCed, because it is
referenced from one of the `java.lang.Class` objects it loaded. That class is
then referenced by `env->NewGlobalRef(clazz);` - e.g. it a global GC root. As
the `ClassLoader` is never GCed, the `JNI_OnUnload` is never called and cannot
do the cleanup.
Memory leak, I am afraid.
-jt
> [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.h
> tml#JNI_OnUnload
> El 8/4/21 a las 5:28, Jaroslav Tulach escribió:
> >> JNI_OnLoad(...) {
> >>
> >> // Find the class in OnLoad
> >> jclass clazz = env->FindClass(...);
> >> // And keep a NewGlobalRef for future use...
> >> MyWhateverClass = env->NewGlobalRef(clazz);
> >>
> >> ...
> >
> > That's the recommended approach. However it shall be stated that this is
> > creating a (class loading) memory leak - it is not going to be possible to
> > unload the JavaFX JAR file classes once this variable is initialized. Just
> > FYI, I think we can live with such behavior.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Memory leak was: Manipulating System Classpath with NetBeans
(OpenJFX assumes classes can be loaded by FindClass)
Posted by antonio <an...@vieiro.net>.
Agreed.
I imagine the webkit infrastructure will have a well defined shutdown
process (that may include sending messages to a native event look,
possibly asking the user for permission to close browser windows, or
whatever).
That may be another good place to env->DeleteGlobalRef(MyWhateverClass),
allowing then the JNI_OnUnload call.
Cheers,
Antonio
El 9/4/21 a las 14:21, Jaroslav Tulach escribió:
>> Hi,
>>
>> JNI_OnLoad has a companion JNI_OnUnload [1], which is the perfect place
>> to invoke an env->DeleteGlobalRef(MyWhateverClass), allowing the JVM
>> garbage collector to do a proper cleanup.
>
> That method is called "when the class loader containing the native library is
> garbage collected." However the class loader cannot be GCed, because it is
> referenced from one of the `java.lang.Class` objects it loaded. That class is
> then referenced by `env->NewGlobalRef(clazz);` - e.g. it a global GC root. As
> the `ClassLoader` is never GCed, the `JNI_OnUnload` is never called and cannot
> do the cleanup.
>
> Memory leak, I am afraid.
> -jt
>
>
>> [1]
>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.h
>> tml#JNI_OnUnload
>> El 8/4/21 a las 5:28, Jaroslav Tulach escribió:
>>>> JNI_OnLoad(...) {
>>>>
>>>> // Find the class in OnLoad
>>>> jclass clazz = env->FindClass(...);
>>>> // And keep a NewGlobalRef for future use...
>>>> MyWhateverClass = env->NewGlobalRef(clazz);
>>>>
>>>> ...
>>>
>>> That's the recommended approach. However it shall be stated that this is
>>> creating a (class loading) memory leak - it is not going to be possible to
>>> unload the JavaFX JAR file classes once this variable is initialized. Just
>>> FYI, I think we can live with such behavior.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists