[kaffe] Kaffe CVS: kaffe hkraemer

[Helmer Krämer]

On Mon, 19 May 2003 05:48:41 -0700 (PDT)
Dalibor Topic <robilad at yahoo.com> wrote:

Hi back,

> --- Timothy Stack <stack at cs.utah.edu> wrote:
> > > * libraries/clib/native/ClassLoader.c:
> > > (java_lang_ClassLoader_loadArrayClass) new method
> > 
> > > * libraries/javalib/java/lang/ClassLoader.java:
> > > (loadArrayClass) new method
> > 
> > Why was this added?  And, does your ArrayForName fail too?
> 
> I'm having 4 regression test failures on i386-linux with jit3, among them
> ArrayForName. Since there were zero test failures before, it looks like the new
> array loading code broke something ;) 
> 
> Helmer, could you take a look at what's going wrong?

first of all, failure of these tests doesn't mean that
I commited something that is not working or something,
these tests fail because some not so common actions 
(like loading an array with elements of type void)
result in different error messages than before.

The problem with some of these tests is that I don't
know why they were working before :(

In detail:

- ClassGC:

This test fails because a "duplicate name" error occurs,
which means that a classloader tries to defineClass() a
class it has already loaded and defined before (or at
least tried to do so). 

This test creates its own classloader and loads a class
called "ClassGCTest" with that classloader. Afterwards,
the test runs the garbage collector (while still referencing
the classloader) and thereafter tries to load another class
called "ClassGCTestLater" (via its own classloader). This
class in turn depends on the class "ClassGCTest", which
causes the vm to again load the "ClassGCTest" class via
the test's classloader. Since the test's classloader then
simply loads and defines the class again, the "duplicate name"
error occurs.

The only way how this test can succeed is that the "ClassGCTest"
class gets gc'ed during the invocation of the garbage collector.
This however cannot happen in this case: First of all, every
classloader references the classes it has already loaded and
defined through its loadedClasses hashtable. Since the classloader
that loaded and defined the "ClassGCTest" class (and thus keeps
a reference to it) is still referenced during the garbage collection,
the classloader itself and thus the "ClassGCTest" class cannot be
gc'ed, which in turn means that this test can't succeed.

So I'm either missing something obvious or I don't have a clue
why this test succeeded before.

- ProcessClassTest:

Again, a "duplicate name" error occurrs, but isn't expected
by the test.

In this test case, a class called "Second" is to be loaded,
which depends on a class "DontExist", which cannot be loaded
because its class file doesn't exist. This causes kaffe to
throw a NoClassDefFoundError while trying to bring "Second"
to LINKED. This exception in turn prevents the classloader
that loads "Second" from inserting "Second" into its loadedClasses
hashtable. On the other hand, kaffe itself has created a class
pool entry for "Second" and has recorded that someone tried to
load "Second". Later during the test, "Second" is to be loaded a
second time. Since "Second" is not in the loadedClasses hashtable,
the classloader thinks it hasn't loaded "Second" yet and so loads
"Second" again and tries to define it afterwards. However, since
there already is an existing class pool entry for "Second", this
causes kaffe to throw a "duplicate name" error.

So it seems that this failure is caused by the loadedClasses
hashtable and the class entries not being in sync, which is
why I wonder why it worked before and how we could fix it?

Greetings,
Helmer