On 5/31/06, Antoine Reilles <[EMAIL PROTECTED]> wrote:
Also, if I change the build to avoid the use of subant, by inlining all subprocesses, the build goes farther, since it loads all tom's compiler classes only once, instead of once for each subant part.
Using <subant>, just like <ant>, creates a new project, which duplicates the property and reference maps, and probably other stuff too. It's not surprising it's taking more memory than using a single project. Ant (and SubAnt, which just re-uses Ant) was an afterthought it looks to me, and is thus very inefficient memory-wise. OTOH, I don't think the classes are reloaded. I don't see why the new project would need to create a new class loader and reload the classes. I'm not sure whether the sub-project shares its ComponentHelper with its parent project.
We are still looking for memory problems in tom, but it looks like tom is not the only one at fault there.
Probably not. Ideally there would be a fork attribute for <ant> (and <subant>) to ensure each sub-build runs in its own VM, ensuring proper release of memory (when the process exists), but it's never been done and is non-trivial, since a cross-process logger/listener thing needs to be put in place, and what to do with references? Serialize them to the sub-project? Not much is serializable in Ant. To solve your problem, you may have to switch to <apply>, which forks a new Ant JVM for each sub-build (in non-parallel mode), which would emulate fork=true for <ant>. --DD PS: The fact that it still OOME even with inline compiles kinda indicates the memory used by Tom for an earlier compile is not released when memory is getting scarce, so strong ref. to big data is still being help on to. That's the same symptom as Javac used to exhibit before 1.4. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
