initiating class loader lists

Thread view:

Julian Bartram - 14 Feb 2005 02:33 GMT

Hi!
I'm a little confused about the way java virtual machines maintains the
initiating class loader lists. Do VMs on every loadClass() invocation an
stack inspection or...?

Thanks!
Julian Bartram

Reply to this Message

Chris Uppal - 14 Feb 2005 13:04 GMT

> I'm a little confused about the way java virtual machines maintains the
> initiating class loader lists. Do VMs on every loadClass() invocation an
> stack inspection or...?

It looks as if this discussion:

http://sources.redhat.com/ml/mauve-discuss/2004-q1/msg00024.html

has the answer.

-- chris

Reply to this Message

Julian Bartram - 14 Feb 2005 21:52 GMT

>>I'm a little confused about the way java virtual machines maintains the
>>initiating class loader lists. Do VMs on every loadClass() invocation an
[quoted text clipped - 3 lines]
>
> http://sources.redhat.com/ml/mauve-discuss/2004-q1/msg00024.html

That's not exactly what I meant, but thanks anyway. Interesting
discussion. It is strange how the different VMs handle it (more or less
good). So what I meant was how the VMs 'know' that a class loader is an
initiating loader of class.

Julian

Reply to this Message

Chris Uppal - 15 Feb 2005 11:27 GMT

> > > I'm a little confused about the way java virtual machines maintains
> > > the initiating class loader lists. Do VMs on every loadClass()
[quoted text clipped - 4 lines]
> So what I meant was how the VMs 'know' that a class loader is an
> initiating loader of class.

Judging from the discussion -- which seems persuasive to me, though I'm no
authority -- the JVM will record the initiating classloader only when /it
itself/ started the process of class lookup (when resolving references in
another classfile). In such cases, it knows which classloader /loaded/ the
class its working on, and that will (if I've understood the issue correctly) be
counted as the initiating classloader for the referenced class[*]. If a class
is loaded via Class.forName() or similar, then the JVM does not appear to
record an initiating classloader.

[*] Or rather, something like that. I notice that if I load a class via an
explicit classloader, cl, then any classes that it refers to do /not/ get
recorded as having cl as the initiating classloader, although they are recorded
as being /loaded/ by that classloader (when they are, of course). Which
suggests strongly that my understanding of this issue is not, in fact, correct,
or is at best incomplete :-(

-- chris

Reply to this Message

Julian Bartram - 15 Feb 2005 22:41 GMT

>>>>I'm a little confused about the way java virtual machines maintains
>>>>the initiating class loader lists. Do VMs on every loadClass()
[quoted text clipped - 16 lines]
> is loaded via Class.forName() or similar, then the JVM does not appear to
> record an initiating classloader.

Yes, that should be correct, but VMs handle this very different. I made
the following test:

---
TestClassLoader loader = new TestClassLoader();
Class classe = loader.loadClass("TestClass");
System.out.println(classe.getClassLoader());
System.out.println(loader.findLoadedClassTest("TestClass"));

classe.newInstance();
System.out.println(loader.findLoadedClassTest("TestClass2"));
System.out.println(loader.findLoadedClassTest("java.lang.String"));

System.out.println(loader.loadClass("java.lang.Float"));
System.out.println(loader.findLoadedClassTest("java.lang.Float"));
---

findLoadedClassTest() simply delegates to findLoadedClass().
Class TestClass refers to TestClass2 (which the system class loader see)
and java.lang.String and its class loader is "TestClassLoader". So
TestClassLoader should be (at least after classe.newInstance()) an
initiating class loader of TestClass2 and java.lang.String.
java.lang.Float is loaded explicitly and TestClassLoader could record it
(or rather the VM).

JamVM's output is:
TestClassLoader@401a8848
class TestClass
null
null
class java.lang.Float
null

Kaffe's:
TestClassLoader@81b9458
class TestClass
class TestClass2
class java.lang.String
class java.lang.Float
null

Sun's VM throws an IllegalAccessException Exception.

I did not consider whether it violates any constraints (cause Sun's
exception), but Kaffe behave as expected.

But how the VMs 'know' that for excample TestClassLoader is an
initiating loader of class TestClass2. I think the only way to do so is
to recognize and inspect the parent.loadClass() calls (in case of the
gnu classpath api).

Julian

Reply to this Message

Robert Lougher - 16 Feb 2005 22:36 GMT

Hi,

It's 10pm in the UK, after a long day in work so I don't want to write
a long explanation as I'll probably get it wrong :) What I do want to
explain is why JamVM reports "null" when it shouldn't do...

You're correct in working out that it's the VM which records the
initiating loader. It does this when it resolves a reference to a
class from a class loaded by a class loader. For each class, JamVM
maintains a reference to the defining class loader for it (null for the
bootclasspath loader), and a list of class loaders which were used in a
resolution attempt (the initiating loaders - the defining loader is
implicitly part of this). As this is only done by the VM, direct calls
programmically to the class loader aren't recorded.

So, from your description below, JamVM will have recorded
TestClassLoader as an initiating loader of TestClass2 and String.
However, it returns "null" because of a bug in Classpath. In fact, if
you read the message that David Holmes responded to, you'll see I
mentioned it:

http://sources.redhat.com/ml/mauve-discuss/2004-q1/msg00022.html

The problem is that ClassLoader in Classpath maintains its own list (in
Java) of the classes that it has defined -- this is what is searches
when you call findLoadedClass. Of course, this won't contain any of
the classes that the VM has recorded the loader as being as initiating
loader for. This can probably be traced back to a change Sun made in
the documentation for findLoadedClass between Java 1.3 and 1.4.
Initially it just said returns the classes loaded by this loader, which
is pretty vague. In 1.4 they tightened it up and explicitly stated
recorded as an initiating loader by the VM. Classpath is arguaby OK in
1.3, but is definately wrong against 1.4.

I initially fixed it by providing my own implementation of ClassLoader
along with all the other VM classes that are needed to interface
Classpath to a particular VM. This version overrode the one in
Classpath, and made findLoadedClass a native method implemented by the
VM. However, I removed it in JamVM 1.2.3 because of incompatible
changes between ClassLoader in Classpath 0.12 (if I remember) and the
CVS development version. I couldn't make my version compatible with
both, and I decided it was more important to have JamVM work with the
snapshot (for "ordinary" users) and CVS, for the Classpath developers
themselves (who use JamVM).

I'll raise it as a bug, and have findLoadedClass moved into the "VM
layer". In the meantime, the native implementation is still there in
JamVM 1.2.4. If you're feeling particularly interested, you can edit
ClassLoader in your Classpath installation and change findLoadedClass
to be native. It'll then use JamVMs implementation.

Good luck!

Rob.

> Yes, that should be correct, but VMs handle this very different. I made
> the following test:
[quoted text clipped - 45 lines]
> initiating loader of class TestClass2. I think the only way to do so is
> to recognize and inspect the parent.loadClass() calls (in case of the

> gnu classpath api).
>
> Julian

Reply to this Message

Julian Bartram - 17 Feb 2005 01:23 GMT

Hello!

Thanks for your detailed explanation.
By the way, I made a mistake. Sun's VM handle it in the same way as Kaffe.

Reply to this Message

initiating class loader lists

Free Magazines