[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnu_java_awt_peer_gtk_GdkFontPeer.c (initStaticState): missing NewGl

From: Mark Wielaard
Subject: Re: gnu_java_awt_peer_gtk_GdkFontPeer.c (initStaticState): missing NewGlobalRef?
Date: Sat, 03 Dec 2005 21:08:59 +0100

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?



Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]