[kaffe] State of the Verifier

[Timothy Stack]

> Hi Tim,

hi,

> If I'm not mistaken, analyzeMethod() is called right before executing a
> method for the first time from either the interpretter or the JIT engine,
> so at that point it is perfectly OK to raise an exception regarding the
> inability to find a specific field in a class or a specific class
> referenced by a method.

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.

> 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).
> 
> So, for example, if a method being invoked expects something of type A on
> the (simulated) operand stack, and there is something of type A on the
> operand stack, there is no need to load type A at all as you know its OK.  
> However, during verification you still need some kind of a handle on type
> A, such as a pointer to its Hjava_lang_Class instance.

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.

> At the moment, when trying to find a class the VM grabs its classEntry in
> the classPool, and if the entry's Hjava_lang_Class object is NULL it goes
> ahead and loads the class, which is what I would like to avoid under
> certain circumstances.  What I would change is to make it check something
> like msize == -1 (a new initial value) instead of class == NULL. This way,
> when the verifier sees something of type A but doesn't need to load it, a
> classEntry can be created and memory allocated for the Class instance
> without causing the class to be loaded until it is needed later during
> execution.
> 
> Does that seem reasonable?  If not, then I think I might have to start
> using classEntry's instead of Hjava_lang_Class pointers throughout the
> type checker...

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.

> Thanks,
> Rob

tim