ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kerns, Bob" <Bob.Ke...@firepond.com>
Subject RE: [PATCH] build listener class loading
Date Sun, 20 Jan 2002 10:10:37 GMT
I'm well aware that tools can (and should be able to) run Ant indefinately
in a single VM. I should have made that clear; as a result, you've missed
the point.

The only cleanup that's critical for running indefinitely is closing the
open zipfiles. And that's managed as a cache, so closing them *does not
break the Project*. (Though if they get reopened later because of the event
firing at the wrong time, then you've failed to support running
indefinitely).

But clearing out the pathComponents and the project from the classloader is
neither necessary nor sufficient for the goal of running Ant indefinitely. 

First, the pathComponents represents a relatively small, fixed amount of
memory per classloader instance.

Second, if the classloader instance should be being GC'd anyway. All you are
accomplishing is allowing these things to be GC'd during the window between
when the event fires, and when the last reference to the task class &
classloader are dropped. (With a reasonable amount of VM, the odds of a GC
occuring in this window are quite low!).

On the other hand, if these things would NOT be GC'd if you didn't drop
these references, then this implies that the classloader is NOT being GC'd
-- hence this is not sufficient, and you need to address THAT problem. (And
addressing it, will address this one).

I suspect you've done a fair amount of competent C or C++ programing before
you became a Java programmer, no? With Java (and other GC'd languages), you
don't have to do these things, and as a result, you don't have to suffer the
bugs this sort of thing engenders (as in this case). [That's not to say you
don't have to pay attention to memory usage issues -- just not in this sort
of way!]

Finally, I'm also well aware that Launcher.java is not currently used. I
just grabbed it as an example of how I thought this SHOULD be handled. I
should have avoided this confusion by using Definer.execute() as my example
instead. If I HAD used that specific example, I would have answered that
part of my question myself:

The creator of the AntClassLoader doesn't always create the loader in
question outside the scope of running the project (as in Definer.execute()).
Thus, the classes loaded by the classloader can remain in use (and cause the
classloader to be used) long after the creator of the classloader exits.

And thus, the change this is responding to IS needed, because we need to
clear the zipfile cache *after* the last use, or we may leave zipfiles
reopened. (Or alternatively, manage the zipfiles as a global cache of
bounded size).

However, it still looks to me like clearing out project and pathcomponents
and IntrospectionHelper's is a premature optimization.

Finally (but not terribly relevantly...) I note that a taskdef or other
class loaded with the classloader could spawn another thread, and thus
potentially need to load classes *indefinitely* until GC'd, at which point
everything except the open files underlying the zipfiles would be reclaimed.
Though perhaps breaking taskdefs that do this could be regarded as a
feature... ;=). I only mention it because it supports the philosophical
point that it's better to let the GC determine when an object reference is
no longer needed. [But we're not here to argue philosophy].

-----Original Message-----
From: Stefan Bodewig [mailto:bodewig@apache.org]
Sent: Wednesday, January 02, 2002 8:31 AM
To: ant-dev@jakarta.apache.org
Subject: Re: [PATCH] build listener class loading


On Mon, 31 Dec 2001, Bob Kerns <Bob.Kerns@firepond.com> wrote:

> I was sort of wondering why these cleanups exist. It looks to me
> like perhaps there's some premature optimization going on here, and
> some poorly-allocated division of responsibility.

The cleanups are there for things like CruiseControl (see the External
Tools page) that runs Ant repeatedly in a single VM that could be
running for years.  Without the cleanup code, you will very soon run
out of memory.

> refactoring the code in Launcher.java:

Launcher.java doesn't get used ATM.

When I get closer to my development box (currently ssh over a 28.8k
modem), I think, I'll remove all unused classes from Ant's main cvs
tree. 8-)

Stefan

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message