stack overflow interacts poorly with classloaders

[Jason Baker]

Patrick Tullmann <tullmann at cs.utah.edu> writes:

> Tim Stack wrote:
> > Preloading in this case means checking if a class references
> > StackOverflowError or any of its ancestors and then having the class
> > loader load them in, or we just treat them as "special classes" that
> > magically resolve to system classes regardless of the class loader.
> 
> I'm not sure if that's sufficient.  For example this code:
> 
> 
> 	...
> 	try {
> 		wasteLotsofStackSpace();
> 	} catch (SomeAppSpecificException i) {
> 		...
> 	}
> 	...
> 
> may still invoke the ClassLoader and call out into Java code in the
> exception dispatching path.
> 
> The problem is really that the exception dispatch path may wander out
> into arbitrary Java code (via loadClass()).
> 
> It seems to me that the solution is to make sure that all Class names
> referenced in a catch clause are resolved before any code in the
> corresponding try block is executed.  Can we just get away with making 
> sure all class names referenced in a catch block are resolved when the 
> method is compiled?  

That seems fair, since the JVM is supposed to check that they are <:
Throwable anyway.  As for classes loaded by the catch body, is this
really a problem?  Once a StackOverflow has been dispatched, we
should be able to throw a new one and make progress.

Jason