[kaffe] State of the Verifier

[Rob Gonzalez]

Hi,

> Unfortunately, the spec is vague/loose in regard to when the linking
> exceptions are thrown.  But, generally, I would prefer them to be thrown
> as late as possible, preferably at the first active use.  This also seemed
> to be the direction the pocketlinux version was heading.  Heres an example
> from the JanosVM release notes:
> 
>   * Support was added to make class loading lazier.  Compiled methods
>     will now defer loading classes until the code is executed.  For
>     example, the following code will not load the 'Bar' class until
>     'a' is true:
> 
> 	public void foo(boolean a)
> 	{
> 	    if( a )
> 	    {
> 		new Bar().b = 42;
> 	    }
> 	}
> 
>     The deferral is done by having the method call a function in
>     soft.c that loads the class and, in the above case, returns the
>     address of the field.  Unfortunately, the INSTANCEOF and CHECKCAST
>     bytecodes still aggressively load classes during verification and
>     not when they are actually referenced.

I don't see why instanceof or checkcast would need to be loaded
aggressively during verification, but my hunch is that they're dealing
with some of the same issues that I am.  Namely, when checkcast is
performed during execution simulation you'll need to be able to load a
pointer to the class for type checking... I'll drop the JanosVM people a
line to clarify this point.

But yes, the lazy loading is what I'm trying to accomplish.


> > verify3() is called when a class is about to be linked.  At this point,
> > according to the JVM spec you're not supposed to check whether a given
> > class has a given field, or even whether a given class exists _unless_ you
> > need that class for type checking (i.e. if you expect something of type A
> > and have something of type B, then you have to load B to see if A is in
> > its superclass type hierarchy).

> Can't you just use the signature like in code-analyse.c.  Theres already a 
> bunch of code in lookup.c for taking care of this stuff.

Not really.  The getField() and getClass() and getClassFromSignature() and
stuff like that all cause the referenced class to be loaded and, in most
cases, linked.


> I'm just not convinced you need to mess with class loading to do this.  
> There is a lot of complexity and subtlety in loading and I would really 
> like to avoid touching it without good cause.

I'm not really talking about any serious modification to class loading.  
All that would happen is that the memory allocation of the
Hjava_lang_Class instance would happen earlier, allowing me to have a
pointer to the class for type checking without loading the actual class.  
Again, right now the memory allocation is tied to the actual class
loading.  Everything else would remain as is.

Essentially, every time a "if (class == NULL)" appears (more or less), a
check to something like "if (class->msize == -1)" would replace it.

Also, I'd create a couple methods that take advantage of this.  For
instance, in my copy of the code I actually have new methods such as
loadClassToState() that load a class only to a specified state
(loadClass() becomes a call to loadClassToState() to the default target
state).


Maybe I'm not explaining this well or maybe I'm overlooking some
complications.  Admittedly, I'm certainly not an expert about the class
loading system of Kaffe.  However, I'm pretty sure what I'm planning on
doing isn't going to interfere with anything else, as classes will still
be loaded through code-analyze just before they are needed at execution of
a method.  Should I post a patch that you can look at to better decide
whether what I'm doing is a bad idea?


Thanks,
Rob