[kaffe] State of the Verifier

[Rob Gonzalez]

Hi Tim,

> > * Need to Rewrite Class Loading
> >     I've been frantically debugging the verifier in the last week against
> >     the regression tests and other programs.  It turns out that I'm going
> >     to have to rewrite some of the class instance creation code in the
> >     core vm to allow type checking without class loading to occur.
> 
> Are you talking about things like the following in code-analyse.c:
> 
> 	if (getField(WORD(pc+1), meth->class, false, &finfo, einfo) == 0) {
> 		failed = true;
> 		goto done;
> 	}
> 
> If so, the JanosVM already has many of the necessary changes, please 
> pull/reference that code.  Also, dropping loading at this point means you 
> have to find another place to load the classes.  You can't do it while 
> jitting because of locking issues (the jitter isn't reentrant so you 
> can't compile a user class loader).  So you have to do it between 
> verification and jitting or do it in the jitted code (JanosVM does the 
> latter).
> 
> If not, please elaborate...  a lot

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.

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.

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...


Thanks,
Rob