[kaffe] circular linking difficulties

[Helmer Krämer]

On Sun, 27 Jun 2004 15:10:22 -0400 (EDT)
rob at kaffe.org wrote:

Hi,

first a question about the verifier ;)

mergeTypes() contains the following snippet:

 	mergeSupersets(v, t1, t2);
	if (v->supertypes->count == 1) {
		*t2 = *TOBJ;
	}
	else {
		t2->tinfo = TINFO_SUPERTYPES;
		t2->data.supertypes = v->supertypes;
		return true;
	}

Is this really correct? If supertypes->count is 1, this means
that both classes have a common superclass and that should be
the result of the merge, shouldn't it?

> Does anybody see a good way to deal with this problem?  If it helps, I can
> post a couple Java classes that display the error in the current CVS head
> when it's run with -verifyremote as an option.

What puzzles me is that we already have the CSTATE_DOING_LINK phase
during class loading, which seems to be what you want: In your example,
A's state will be CSTATE_DOING_LINK during verify3(A). If the same
thread that executes verify3(A) tries to load A again before verify3(A)
is finished, A will be treated as if it was CSTATE_LINKED already.
This means that the verify3(B) call executed during verify3(A) will
treat A as if it was already CSTATE_LINKED. Therefore, verify3(B) will
succeed and afterwards also verify3(A). Since this is not working as
expected, I either missed something or something else is going wrong.

[have you tried setting "class->processingThread = THREAD_NATIVE ();"
just after the "SET_CLASS_STATE(CSTATE_DOING_LINK);" in classMethod.c?]

This will also work with user class loaders. When kaffe delegates
loading of a class to a user class loader it always calls loadClass
with resolve set to false. This means that a "correct" class loader
will call defineClass(), but not resolveClass(). Therefore, the
class returned by loadClass() will be PREPARED, but not LINKED or
even COMPLETE. This only fails if the user class loader ignores the
resolve parameter and processes the class to COMPLETE (either by
calling resolveClass directly or by creating an instance of the
class returned by defineClass). This however would mean that the
class loader is not "correct".

Regards,
Helmer