Re: Class loader optimization patch

[Mark Wielaard]

Hi,

On Mon, 2003-03-03 at 23:08, Prof. Etienne M. Gagnon wrote:
> 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?

I agree that anything that goes beyond what Jeroen posted should
certainly be measured first to see if it makes a difference in real
world applications. And that goes double for the ideas that I prefixed
with "Skip this part if you don't like speculative, ugly, unproven
hacks" :)

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

It is mainly startup time that can be reduced somewhat. Big applications
such as Eclipse create a new ClassLoader for every component (and stack
them for subcomponents). That means that every class that is loaded
often goes through three classloader parents. Given the fact that there
are hunderds of classes being loaded that way you can prevent thousands
of short lived objects if you don't have to throw a couple of No
ClassDefFoundExceptions for every class that is requested.

But I agree this is all a bit experimental. GNU Classpath based VMs have
only recently been able to run things like Eclipse. But it already shown
me a couple of speed improvements. The ZipFile speedups for example were
very noticeable on Eclipse Loading time. And the (lib)gcj runtime has
certainly seen some nice improvements by just looking for the
bottlenecks that showed up while starting Eclipse.

Note that this is a very nice speed tests for the different VMs. It
takes minutes before the main Eclipse Window shows up even on a fast
machine. Maybe we can have a price for the first VM that manages to load
Eclipse under one minute on some standard PC (say 1Ghz Athlon/Pentium
with 512MB).

Cheers,

Mark