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:[EMAIL PROTECTED] Sent: Wednesday, January 02, 2002 8:31 AM To: [EMAIL PROTECTED] Subject: Re: [PATCH] build listener class loading On Mon, 31 Dec 2001, Bob Kerns <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
