classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Class loader optimization patch


From: Mark Wielaard
Subject: Re: Class loader optimization patch
Date: 03 Mar 2003 22:34:04 +0100

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]