ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: FW: Problem with ANT classloader?
Date Mon, 20 May 2002 03:06:36 GMT
Steve Loughran wrote:
> I havent found it to be that much slower. A fair amount of the java exe and
> runtime libraries are already in memory and disk cache when you spawn the
> new JVM, so although there is startup hit, you dont pay the penalty of
> loading all the stuff in from HDD again. I havent done enough rigorous
> experiments to say this is a consistent truth, so in ACM terminology this is
> "an observation", not "a finding". Its enough of an observation for me to
> always set fork=true and not worry about things. Also when you fork you get
> System.exit() handling, proper-like, and better leakage handling.

Agreed, although the startup hit may be significant for a short lived 
<java> task.

> I have that patch to do (1) posted a few weeks ago, and a better solution,
> derived from Dominique's suggestions (move it all to JavaEnvUtils, return a
> String array of intrinsic classes). The problem doesnt grow very fast, only
> at the rate of new java versions, so is tractable. Indeed, we should add
> some of the org.omg classes and even sun.misc for various bits of code to
> work in-JVM,.

Let me just add that the javax package itself represents something of a 
problem. As time goes on parts of this package move from something found 
outside the VM (it may be provided by an app server, for example) to 
classes within the VM.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message