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.

Bug 41689 - Run Ant in its own VM to work around buggy tasks
Summary: Run Ant in its own VM to work around buggy tasks
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Jesse Glick
: 35656 82266 (view as bug list)
Depends on: 206791
Blocks: 47645 170917
  Show dependency tree
Reported: 2004-04-04 20:02 UTC by gugrim
Modified: 2011-12-29 18:06 UTC (History)
1 user (show)

See Also:
Exception Reporter:

A simple ant task that grabs an amount of memory and doesn't release it (401 bytes, text/plain)
2004-04-17 17:23 UTC, gugrim
A build file that uses the leaking task (363 bytes, text/plain)
2004-04-17 17:24 UTC, gugrim

Note You need to log in before you can comment on or make changes to this bug.
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