I can try to investigate, but I will warn in advance that I do not see
such behavior and run Ant from the IDE all the time. Perhaps it has
something to do with Win2000; I run Linux normally. (However many
users run Win2000 and such a problem is not generally reported as far
as I know.) What exact JDK are you using? Can you send samples of
build scripts that cause the problem?

Since such reports are notoriously hard to reproduce, it would be
great to have an *exact* description of your environment--how much RAM
you have, which JDK, which NetBeans (3.2.1 release I assume?), and
your exact build script and suitable data for it to work on.

You might want to try a beta of NetBeans 3.3. We recently introduced a
"memory meter" on the toolbar (turned off by default, you can turn it
on with a right-click on the toolbar area). For me, when running Ant
scripts the memory goes up of course, gets close to the max, and stays
there, and after the script is done goes back to its stable level at
about 50% usage.

Note that if you run a single massive compilation command, you ought
to have enough memory set for NetBeans (-Xmx96m, e.g.) to handle all
of it at once. This should rarely be necessary though. After the
command is completed, the memory ought to be reclaimed, so this only
pertains to temporary memory requirements.

Also if your problem is limited to <javac>, you might try setting a
different compiler: jikes, or (in Ant 1.4.1 in NB 3.3) extjavac etc.
Internal Javac as invoked by Ant is basically a hack (uses
undocumented entry points) and is known to not clean up after itself
well (ultimately Javac's fault but only manifested when called in this
way, not when used as a standalone tool in the supported way). Some
time ago I was able to track down a user complaint about this and
filed a bug with the Ant project. Note this involved holding file
locks on JARs too long; it was not a memory leak in the normal sense.
I doubt it will be fixed though; nobody knows how to invoke Javac any
more safely without forking a process or otherwise slowing it down
significantly.

I cannot reproduce any leak using the Nov 15 development build. As a
test case, I prepared a copy of all of NetBeans' own org.openide.*
Java source files, over 500, and an Ant build script which compiles
them all (using the internal "modern" Javac compiler), then deletes
the class files and starts over, running ten times in a row. This
takes about five minutes of heavy activity on my machine (256Mb,
500MHz).

On Linux (2.2.12) with JDK 1.3.1_01, it was able to run with no
problems; I didn't specifically measure memory, but certainly there
were no OutOfMemoryError's. On Windows 2000 using JDK 1.3.0, I ran the
complete 10x suite at least twice, examining memory usage with Task
Manager. I also left the NB memory meter on, which shows how much Java
heap memory is in use and how much collected and when. While going
through a suite, the memory reported for runide.exe did rise very
slowly (maybe a couple of megabytes by the end of the suite), though
there were several garbage collections which continued to restore heap
size to its previous size; after a suite had completed, and after
doing a manual Garbage Collect just to be sure, memory use in Task
Manager dropped again (to a bit below where it started actually).
During the suites, system RAM consumption as reported in TM's third
panel remained quite constant.

So I will assume this is an idiosyncrasy in your environment unless
there are details to reproduce. Reported memory consumption is not a
terribly reliable figure anyway; OOME's indicate an actual problem
(especially if they are not thrown after one or two iterations of a
build, but only after repeated runs, meaning that your total heap size
is OK and the app really is leaking).

By the way NB development builds set a maximum heap size of 96Mb, I
believe this is the same as in 3.2.1 but if not then try passing
-J-Xmx96m.

If you do still see leaks, I would definitely recommend you try one of
the other tools which runs Ant in-process repeatedly, and compare. For
example, Antidote, or the "ant shell" which has been mentioned on
ant-dev@jakarta.apache.org and should be available for download
somewhere. If these leak too on your build script, then you might be
seeing a problem in Ant itself (more likely its use of other software)
and you should report this as an Ant bug on the Jakarta website. The
NetBeans integration does not do much when running Ant other than call
its standard entry points, so it should be comparable to these other
tools, other than baseline memory usage which of course is higher
since it is an IDE with other functions.

Resolved for 3.3.x or earlier, no new info since then -> closing.

Resolved for 3.3.x or earlier, no new info since then -> closing.