[kaffe] State of the Verifier

[Rob Gonzalez]

Hi Tim,

After looking into backporting the JanosVM design, I've decided to leave
the class loading system largely alone, with the exception that loadClass
will have a new parameter that allows you to specify to what target state
a class should be loaded until.  The new method is called
loadClassToState, and loadClass simply forwards a call to loadClassToState
with the default target state.  The reason for this is that, during
verification, if I really need to load a class, I don't want to link it
(that can cause circular dependency problems when loading on the same
thread), but only get it to the point where I can see its superclass.  If
you can see any problems with this, let me know.

Instead of touching the rest of the loader, I'm dealing with lots of
string comparrisons of names and type signatures in the verifier.  Thus if
I don't need to load a class but know its name, I treat it's name as its
type.  Lots of casts and shit, a little messy, but it gets the job done
without messing with the loader.


Cheers,
Rob


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