Community
Participate
Working Groups
Exposing the option to "reuse the Ant classloader for each build", seems complex. It exposes an implementation issue, and is a workaround for two things: (1) Task development (requires a new classloader to see new classes) (2) Garbage Collection (re-using a classloader leaks memory) To solve both issues require a new classloader should be used on each run. Thus, we should likely drop the option, and just always use a new classloader. This means worse time performance, but better stability for the SDK (avoids memeory leaks), and task developers to do not need to understand the implications of task development.
The speed hit will not just be for a build...this will impact the external tools launch configuration dialog (targets tab) and the Ant view. Task developers should tend to be more advanced users and should understand the implications of task development. We should work with the jakarta ant project to help find and fix the memory leaks...even though these will not appear until the next Ant release. We could get a better idea about how much memory is leaking and every X uses of the Ant classloader create a new one to reclaim the memory.
Having an option that enables a memory leak behaviour isn't an option. Since Eclipse will be blamed for being memory hungry and it is unlikely that a new Ant release becomes available until we ship 2.1. In addition writing Ant Tasks is trivial and common and we should not make it special in any way in Eclipse. Finally, the fact that we run Ant inside the Eclipse VM is an implementation detail that we should not surface in the UI (which we do once we expose the Ant ClassLoader) Bottom line: I'm on DarinW's side
The only issue I have with this is that I seem to recall it having HUGE performance implications. If I recall correctly, this change improved the startup time of our AntRunner by something like a factor of 10.
Just to make sure we are all on the same page...that cached classloader has been in use since Oct 2 (please see bug 20557). We just added the ability for the user to not use the cached classloader. I agree we can never guarantee that Apache Ant will not leak (even if Ant was perfect, the user can load a custom task that could leak like a sieve). I agree we will take a performance hit removing the caching of the classloader (bug 20557). The nice part is I can easily turn off the caching of the classloader ;-)
>it having HUGE performance implications. The performance improvements are significant only when measured against an empty Ant script. Most Ant scripts perform significant tasks and the performance gain becomes less signifcant. >that cached classloader has >been in use since Oct 2 (please see bug 20557). understood and since then we are leaking. The leak is significant I had to restart Eclipse when I used Ant extensively. Finally, if we want to insulate Eclipse from running Ant then using a separate class loader for each run is the right thing to do. Given that Ant is extensible with plugins there can always be memory leaks caused by a plugged-in task. Suggest to remove this option for M4 given that the focus of this milestone is also on footprint.
The ant support always uses a new classloader. Please verify (DarinW).
Verified.
