Bill,
I don't know, but I would hope you are right.
But it might be efficient in an overall sense, but not very smart
about pre-reading additional data and/or doing reads that are not
efficient for fast disks.
For example, it might be used a 16K or 32K buffer, when it ought to
be doing 256K or 512K at a time.
Or it might just load each class as it is requested, rather than pre-
loading the class bytes of other classes in the background; then
every time something is needed it's the bottleneck.
Lloyd
On Aug 15, 2006, at 12:03 AM, Bill Shannon wrote:
> Scott Oaks wrote:
>>> What I don't "get" is why the other modules don't perform their
>>> initialization in a separate thread, with suitable threading
>>> locks or barriers when there are dependencies. The server
>>> *should* be able to start up in about 2 seconds on my MacBook Pro.
>> One thing that impacts this is the Java classloading hierarchy; all
>> class loaders used by the appserver delegate to the system
>> classloader,
>> so that becomes a big single-threaded bottleneck. We are
>> investigating
>> ways to improve this in 9.1.
>
> Is the system classloader really that big of a bottleneck?
> *Everyone* uses the system classloader, I would expect that
> it had been well tuned and multi-threaded by now. If not,
> looks like we have feedback for the Java SE group!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>