Re: Class loader optimization patch

[Prof. Etienne M. Gagnon]

Hi,

Just a couple of thoughts...

I know that throwing exceptions might slow down class loading (yet,
there are clever tricks that more complex JVMs can do to significantly
reduce the cost of exceptions), but has anybody made time measurements
to see if the potential gains in performance of *moslty* eliminating
exceptions from class loading is worth the proposed efforts?

I am not convinced that the final solution would be easier to maintain
(specially in the context of adding a verifier to a VM).  If class
loading counts for less than 1% of the execution time, in most
non-HelloWorld applications, maybe we should simply leave the public
interface as it is, and only modify when bugs are found?

Or, maybe there's another motivation for this change that I missed?

Etienne

On Mon, Mar 03, 2003 at 10:34:04PM +0100, Mark Wielaard wrote:
> Hi,
> 
> On Mon, 2003-03-03 at 17:27, Jeroen Frijters wrote:
> > I made another attempt at reducing the number of ClassNotFoundExceptions
> > that are thrown when loading a class, this time I believe the patch can
> > be integrated without breaking anything. No API changes and existing
> > code should continue to run fine. If the VM implementation of
> > VMClassLoader.loadClass throws a ClassNotFoundException, fine, but with
> > this patch it can also return null, and thus prevent the creation of a
> > (in some cases) useless exception object.
> 
> I like it. The only thing that I would (not) change is the signature of
> the VMClassLoader loadClass() method. Your patch removes the exception.
> We should just document that throwing the exception will sometimes
> create a unused object so returning null is more efficient.
> 
> I do like your earlier proposal even though it changes the public API
> slightly. As long as it is compatible with other implementations I don't
> see to many troubles. We might want to introduce an interface
> gnu.java.lang.OptimizedClassLoader that defines a optimizedFindClass
> method that returns null if it cannot find a class. Our system
> (application) classloader and URLClassLoader should implement it.
> 
> Skip this part if you don't like speculative, ugly, unproven hacks:
> [If we really don't want to introduce any public visible methods to the
> standard classes then we might want to do something "clever" with
> ClassLoader.getParent(), URLClassLoader.newInstance() or even the
> ClassLoader(ClassLoader) constructor that transparently replace a
> ClassLoader with its optimized version. (Haven't thought that out
> completely yet...) Another sneaky way would be to call URLClassLoader
> (and other trusted ClassLoaders) findClass() with a classname prefixed
> with some illegal character so they know to return null when nothing was
> found.]
> 
> Another idea for faster ClassLoading. If ClassLoader.loadClass() is
> called for any java.* or gnu.java.* class directly go through the
> VMClassLoader() since no user defined classloader may/should return
> those classes.
> 
> Other opinions?
> 
> Cheers,
> 
> Mark
> 
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/