This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
|Summary:||Run Ant in its own VM to work around buggy tasks|
|Component:||Ant||Assignee:||Jesse Glick <jglick>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||206791|
|Bug Blocks:||47645, 170917|
A simple ant task that grabs an amount of memory and doesn't release it
A build file that uses the leaking task
Description gugrim 2004-04-04 20:02:11 UTC
We use XDoclet a lot from out Ant scripts, and XDoclet leaks memory. This is normally not a big deal when running outside NetBeans, but since Ant is run within the NetBeans JVM the memory can't be reclaimed without restarting NetBeans. It would be nice if you could specify that Ant should be run as an external process. You'd probably lose some features such as the mounted classpath property, but if you don't use them anyway it wouldn't matter.
Comment 1 Jesse Glick 2004-04-07 00:37:10 UTC
If running Ant leaks memory, that is a bug and we will fix it if we can reproduce it. We need precise steps to reproduce the leak from scratch, starting with a fresh build of NB, fresh user directory, Ant script and sample files.
Comment 2 gugrim 2004-04-17 17:23:55 UTC
Created attachment 14442 [details] A simple ant task that grabs an amount of memory and doesn't release it
Comment 3 gugrim 2004-04-17 17:24:48 UTC
Created attachment 14443 [details] A build file that uses the leaking task
Comment 4 gugrim 2004-04-17 17:30:11 UTC
I have just attached a couple of files that illustrate the problem. As I wrote in my initial enhancement request, the problem is caused by bugs in the tasks, not AFAIK in NetBeans. The problem is that NetBeans becomes very sensitive to such bugs since Ant is run inside the NetBeans JVM.
Comment 5 Jesse Glick 2004-04-18 15:44:53 UTC
Re. buggy tasks: sorry, but you need to get the bugs in the tasks fixed. Leaks in tasks would also harm various other Ant containers, and would even harm command-line Ant if you just used the task too many times. Ant tasks are responsible for cleaning up after themselves, and where the basic operation of the task is known to leak memory with no apparent workaround (e.g. running Javadoc, last I heard), the task is responsible for forking a VM to do the dirty work. Re. this particular case: as of NB 3.6 the entire Ant installation is supposed to held by a soft reference, and also leaks held by task classes ought to be collected when the project goes away; so the task and script you mention should not leak memory permanently (though it may take a while for the VM to collect it, depending on GC policy). When I get a chance I will take a look at your example and check it in a profiler to see if there is any permanently unreclaimed memory.
Comment 6 gugrim 2004-04-19 18:38:47 UTC
I'm using 3.6 and every Ant run steals a few MB's of memory. I always pump the Memory tool bar after a run. After some time I get OutOfMemoryExceptions and often NetBeans can't even be closed because of these exceptions. I'm pretty sure it's the XDoclet tasks that are responsible, and there is little hope that these bugs will ever be fixed. But that is not really the point here. There will probably always be Ant tasks out there that has memory leak bugs, especially since such bugs are easily overlooked when using Ant in scripts with comparably short lived JVM's. The "problem" with NetBeans, as opposed to e g JBuilder, is that you don't need to restart it every twenty minutes, so the leak accumulates. When I entered this issue, I choose type ENHANCEMENT. I still think it would be an enhancement to have the option to run Ant in its own JVM. Ideally, the option would be specific to the build file so that you can use it only when you need it, since you'll probably lose some NetBeans specific features.
Comment 7 Jesse Glick 2004-04-19 21:35:17 UTC
OK, will consider in that light, though it will be less useful in NB 4.0 since - common IDE functionality such as debugging or browsing generated Javadoc will require special in-VM tasks in 4.0 due to the new Ant-based project system - stack trace hyperlinking works more reliably in 4.0 if you are running in-VM - desired output formatting features (might slip till 4.1) may require in-VM operation - spawning a new VM to run Ant is slower and would noticeably impair responsiveness of common lightweight operations So I'm not sure how practical it will be in 4.0 to offer such an option (putting aside for the moment the development time to implement it), since normal project build scripts will not work as nicely if run out of VM, unless a rather more complex solution is chosen using RMI or sockets or something like this to enable rich Ant -> IDE communication. Making it a per-build-script choice (default to run in-VM) would be technically straightforward but the UI would be poor and I am not sure many users would discover it. "I'm pretty sure it's the XDoclet tasks that are responsible, and there is little hope that these bugs will ever be fixed." - why? It's open source. If the bugs are reported and someone has an afternoon available to work on them, especially if they are straightforward to reproduce, probably they could be fixed. If the entire XDoclet engine and/or support libraries leaks memory right and left and it is impractical to fix the whole thing, the tasks should certainly have an option to fork a VM when they run - this is not very hard to implement in an Ant task as a rule, and many tasks already offer such an option.
Comment 8 gugrim 2004-04-20 19:20:52 UTC
If, as you say, "making it a per-build-script choice (default to run in-VM) would be technically straightforward", then that sound great. You also say that "I am not sure many users would discover it", but there are so many nice features in NetBeans that isn't always easy to discover. When you really need them, you'll find them, with a little help from your friends at the forum! Concerning XDoclet; The current version is 1.2 and it seems to be quite dead so we'll probably have to live with the bugs.
Comment 9 Jesse Glick 2004-07-24 20:02:58 UTC
*** Issue 35656 has been marked as a duplicate of this issue. ***
Comment 10 Jesse Glick 2004-10-06 15:58:25 UTC
No immediate plans to work on this.
Comment 11 Jesse Glick 2006-08-09 16:05:17 UTC
*** Issue 82266 has been marked as a duplicate of this issue. ***
Comment 12 Jesse Glick 2008-12-10 00:34:34 UTC