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
Ooops! Almost forgot to commit this.
TWISTI
2005-11-15 Christian Thalinger [EMAIL PROTECTED]
* native/jni/java-lang/java_lang_VMDouble.c (initIDs): Register
clsDouble as global ref.
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GtkToolkit.c
(gtkInit):
On Tue, Nov 08, 2005 at 07:09:43PM +0100, Mark Wielaard wrote:
code analyzer for this. Please let us know when the paper is published.
Here is the first version of the paper:
http://www.complang.tuwien.ac.at/cacaojvm//papers/space.dvi.gz
TWISTI
___
On Thu, 2005-11-10 at 20:57 +0100, Mark Wielaard wrote:
These indeed look like genuine bugs. Thanks for finding them. Could you
post the patch plus a ChangeLog entry to classpath-patches and commit
these?
Took some time, but done.
TWISTI
___
On Tue, 2005-11-08 at 16:42 +0100, Christian Thalinger wrote:
We are currently developing a JNI source code analyzer, which scans for
missing NewGlobalRef calls (this is for popl06). And it seems that it
has found a bug in GNU classpath's gtk peers.
Ok, here are the 2 missing jclass bugs
Hi Christian,
On Thu, 2005-11-10 at 20:38 +0100, Christian Thalinger wrote:
Ok, here are the 2 missing jclass bugs we've found:
These indeed look like genuine bugs. Thanks for finding them. Could you
post the patch plus a ChangeLog entry to classpath-patches and commit
these?
There are a lot
On Thu, 2005-11-10 at 20:57 +0100, Mark Wielaard wrote:
Yes, please do post a list if you have one and we can go through them
and see if they might indeed cause bugs/unexpected behavior. Even if
they are not really problematic in this context it would be instructive
what kind of potential
Hi!
As discussed on classpath, this one is commited. Maybe more to come...
TWISTI
2005-11-09 Christian Thalinger [EMAIL PROTECTED]
* native/jni/gtk-peer/gnu_java_awt_peer_gtk_GdkFontPeer.c
(initStaticState): Register global variable glyphVector_class
as global
On Tue, 2005-11-08 at 19:09 +0100, Mark Wielaard wrote:
Yes, nice catch. Now that I have seen this I am surprised we don't have
more bugs like this one. it is easy to miss. Cool to know you have a
code analyzer for this. Please let us know when the paper is published.
We currently have only
On Tue, 2005-11-08 at 18:32 -0700, Tom Tromey wrote:
Twisti == Christian Thalinger [EMAIL PROTECTED] writes:
Perhaps when it is ready we could integrate it into the build, so
that errors here are unavoidable?
Uhm... that will be difficult since the tool is an enhancement of GCC.
It's just
Hi!
We are currently developing a JNI source code analyzer, which scans for
missing NewGlobalRef calls (this is for popl06). And it seems that it
has found a bug in GNU classpath's gtk peers.
In Java_gnu_java_awt_peer_gtk_GdkFontPeer_initStaticState the global
variable glyphVector_class is not
Hi Christian,
On Tue, 2005-11-08 at 16:42 +0100, Christian Thalinger wrote:
We are currently developing a JNI source code analyzer, which scans for
missing NewGlobalRef calls (this is for popl06). And it seems that it
has found a bug in GNU classpath's gtk peers.
In
Twisti == Christian Thalinger [EMAIL PROTECTED] writes:
Twisti We are currently developing a JNI source code analyzer, which scans for
Twisti missing NewGlobalRef calls (this is for popl06). And it seems that it
Twisti has found a bug in GNU classpath's gtk peers.
Very cool.
Perhaps when it
13 matches
Mail list logo
