Re: gnu_java_awt_peer_gtk_GdkFontPeer.c (initStaticState): missing NewGlobalRef?

[Mark Wielaard]

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