ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Reilles <>
Subject Re: subant and memory problems
Date Mon, 05 Jun 2006 13:03:06 GMT
On Sun, Jun 04, 2006 at 09:17:13PM +0100, Steve Loughran wrote:
> Antoine Reilles wrote:
> >Hi,
> >
> >For building the examples of the tom project (, we
> >use the subant task, each example containing a build.xml snippet, using
> >  <target name="build.all">
> >    <subant target="build">
> >      <fileset dir="." includes="*/build.xml"/>
> >    </subant>
> >  </target>
> >Those examples do use the tom ant task to compile tom sources to java,
> >and then javac. The tom ant task require to load the tom compiler, which
> >is a java application. However, we currently notice memory problems when
> >building all examples. For each example, ant do load all tom's compiler
> >classes, but it seems they are never released. thus, after a few
> >examples, ant dies with an OutOfMemory error. Buildinf with -v -d shows
> >ant do load the classes of the tom compiler and all dependancies for
> >each subant task, with
> >
> >[snip]
> >Finding class aterm.ATermAppl
> >Loaded from /home/tonio/workspace/jtom/src/dist/lib/aterm.jar
> >aterm/ATermAppl.class
> >Class aterm.ATermAppl loaded from ant loader (parentFirst)
> >[snip]
> >
> >However, there is no mentions of unloading.
> >Is it possible that ant do retain some memory, and thus causes the
> >failure ? Or are we using the subant task incorrectly ?
> Is there any way to run the compiler in a new process?
I tries the <apply> approach Dominique suggested. It works fine, but i
had to translate the simple
    <subant target="build">
      <fileset dir="." includes="*/build.xml"/>
by something much less elegant
    <apply executable="ant"
      <arg value="-Dtom.home=${tom.home}"/>
      <arg value="-f"/>
      <fileset dir="." includes="*/build.xml"/>
where i need to pass the interesting properties explicitly
This solution is also quite cpu/io expensive

> some compilers (javac was always one) used to build up massive 
> datastructures that would never get released...
Tom also build some massive datastructures and abstract syntax trees,
but those ast are java implementation generated by the gom
tool, and are not faulty here.
I guess the more elegant way would be to add a "fork" attribute to our
tom task, but i don't know how difficult it would be, as to is simply a
java application. We could also simply run the tom compiler using the <java>
task with fork=yes, but that would lead to quite complex macrodef


View raw message