This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
- From: "thebohemian at gmx dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Nov 2005 16:51:15 -0000
- Subject: [Bug libgcj/24616] linking BC-compiled classes: NoClassDefFoundErrors should be deferred
- References: <bug-24616-10268@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #20 from thebohemian at gmx dot net 2005-11-16 16:51 -------
Created an attachment (id=10255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10255&action=view)
lazy linking - part 2
This is the second part of the lazy linking patch. Applying both fixes most of
the problems with BC-compiled classes.
How does it work:
At first I introduced a new class state for classes which somehow exist in the
runtime but cannot be used to the full extent (instantiation, array creation,
field access, ...). In the commentation I named such classes phantom classes
and they are set to the JV_STATE_PHANTOM state when created (which is sometimes
inevitable).
Whenever such a class reaches a _Jv-function that cannot make use of such class
it throws a NoClassDefFoundError. You can see that in
_Jv_AllocObjectNoFinalizer and _Jv_AllocObjectArray. By doing so gij behaves
like the JDK.
There is only one flaw which I am going to tackle tomorrow: The
accessStaticField test case throws a rather odd
StringIndexOutOfBoundsException. I assume that I mixed something up while
trying to make field resolution more lazy.
To my surprise this patch fixes all the problems with gij in interpreted more
although this was not intended.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616