[kaffe] State of the Verifier

[Timothy Stack]

> Hi,

hi,

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

Well, I am the JanosVM person ;)  Anyways, as I said in the reply, I just 
never got around to adapting them like the others.

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

The JanosVM versions don't, so you can try backporting those.

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

Every change to the loader is serious ;)

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

One example I can think of is that it might conflict with error handling.  
At the moment, the loader allows you to reload classes that fail early on,
which mimics the behavior of jdk 1.3.1.  This might not work anymore if 
the class pointer has to be stable and can't be replaced for a failed 
class.

There might be other semantic changes that crop up as well...  Basically,
the only thing I know is that the lookup.c path is much less treacherous
than trying to change the loader.

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

Maybe...  I could also write some tests to make sure the semantics of the 
loader aren't being changed.

> Thanks,
> Rob

tim