Hi Christian, I finally read the paper and took a look at the list. But you already fixed all the obvious things related to class fields. So the remaining things left seem to be jmethodIDs that are cached, but where we don't have a global ref to the class. Like the following:
> B gnu_java_awt_peer_gtk_GtkWindowPeer.c 272 (jmethodID) > B gnu_java_awt_peer_gtk_GtkWindowPeer.c 275 (jmethodID) > B gnu_java_awt_peer_gtk_GtkWindowPeer.c 279 (jmethodID) > B gnu_java_awt_peer_gtk_GtkWindowPeer.c 282 (jmethodID) > B gnu_java_awt_peer_gtk_GtkWindowPeer.c 286 (jmethodID) > B gnu_java_awt_peer_gtk_GtkWindowPeer.c 289 (jmethodID) But are these really a problem? For GNU Classpath they are probably not a problem since these classes and naitve libraries are loaded by the bootstrap class loader so will never be unloaded. But is it even a real problem when the class and the native library are loaded by a user defined class loader? It seems that both the class reference can only "disappear" (and making the mathod id cache invalid) when the class loader is garbage collected. But in that case the native library will also be unloaded. So any method field ID caching will be redone when the class and native library are loaded again. What do you think? Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath