ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Adams" <>
Subject MP & the <parallel> task (Was Re: Win2K vs Sun)
Date Thu, 28 Feb 2002 13:22:06 GMT
>>> 02/27/02 06:51PM >>>
> I dont think the Nt box did spread the load well; 58% per cpu is a 
> balanced 116% of one part...I bet if you looked at the kmode portion of 
> the load (show kernel times in taskman), that 16% would be file IO, not 
> java.

Perhaps - but I'm still puzzled as to why both Sun boxes ran slower than our baseline WinNT4
workstation - they had more physical RAM (1 GB and 2GB versus 512 MB), and a 450 MHz UltraSPARC
should be faster in general than a 750 MHz Pentium III.

> By default ant single threads, javac is also single threaded. nobody has
> added any explicit support for synchronization in their tasks so going MP
> would be dangerous.

Which brings us to our next topic.  The ant scripts we use are roughly based on the antgump
proposal; a master build scripts creates a java process that runs the ant buildfile for each
project.  This java process is forked, so I'm guessing it would be safe to run these builds
in parallel.  Two pitfalls:

Problem #1: Projects are dependent upon each other; building two projects in parallel with
one referring to the other in it's classpath would be bad.

Solution #1: We can set  up a lib directory ${lib.dir} that contains the JARs produced in
the previous build, and put these in the classpath for the current build, thus solving most
project dependency problems.

Problem #2: Our various java process (theoretically running in parallel) won't be writing
to the exact same destination directory (because of packaging differences), but they will
all have the same destdir for their respective <javac> tasks (ie, ${classes.dir}). 
My understanding is that Ant automatically adds this directory to the classpath.  Would this
directory be added before, or after any explicitly added paths?  If project dependencies were
solved by using files from ${classes.dir} instead of the stable JARs in ${lib.dir}, then we
could run into problems.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message