Re: [macker-developer] Patch to help running in a forked JVM under Ant

[Ross B. <ro...@ce...>]

Hi Paul,

Attached is an updated patch. It includes the original changes, as well
as a simple performance improvement - the Ant task no longer calls
macker.addClass()if we are going to fork the JVM.  

This patch should also be closer to macker's coding style - it took me a
while to get used to it!

Once it has enough memory, macker's performance is fine for my
purposes.  To run 20 rules over 7000+ classes takes only about 90
seconds (on a P4 with enough RAM to avoid swapping). I've added macker
as a precursor to a unit test suite that takes about 30 minutes to run,
so that 90 seconds is barely noticeable. 

Ross.
 

On Mon, 2003-11-17 at 16:32, Paul Cantrell wrote:
> Ross --
> 
> Thanks a bundle!  Looks like a great patch.  I should find some time to 
> apply it this week.
> 
> I know that Macker doesn't scale to very large projects all that well.  
> I can make some guesses about where the memory is going, but it would 
> be nice to do some serious profiling and find out for sure.  I've never 
> given it any serious optimization attention, so perhaps now is the 
> time....  Does anybody on the list have profiling tools / expertise?
> 
> Just out of curiosity, how large is the project you're running it on -- 
> how many classes?
> 
> Thanks again for the patch.
> 
> Cheers,
> 
> Paul
> 
> 
> On Saturday, November 15, 2003, at 10:58  PM, Ross Burnett wrote:
> 
> > Hi,
> >
> > Congratulations & many thanks for Macker, it is a useful tool to have!
> >
> > After experimenting with it for a while I'm now integrating it an Ant
> > build environment, and in doing so I've found a couple of issues:
> >
> > 1. Macker slows to a crawl as its memory usage approaches the JVM's 
> > max.
> > In other ant tasks (eg. javadoc) this is normally solved by forking off
> > a new JVM with a large maximum memory. While macker supports forking, 
> > it
> > doesn't provide a way to set the max memory for the new JVM.
> >
> > (I realise I can increase the memory of the original Ant JVM using
> > something like ANT_OPTS=-Xmx256M, but I prefer to keep the Ant
> > environment as standard as possible: the less developers have to alter
> > the better)
> >
> > 2. When forking a new JVM, the macker ant task adds the name of every
> > class file as an argument to the new process. This fails with a largish
> > number of classes, presumably due to the command line being too long.
> >
> > Attached is a patch that aims to solve these issues by doing the
> > following simple things:
> >
> > a. Adding an optional 'maxmemory' attribute to the macker ant task so
> > that the max memory of the forked JVM can be specified.
> >
> > b. Adding support for an indirect input file to macker. A command line
> > argument of the form '@file' means that each line in 'file' identifies 
> > a
> > class file to process.
> >
> > c. Updating the macker ant task so that when forking a new JVM it 
> > passes
> > the list of class files via a temporary @file, rather than listing them
> > all on the command line.
> >
> > The patch was made against the CVS sources as at Sun Nov 16 04:44:14 
> > UTC
> > 2003, using 'cvs diff -b -c'.  Please let me know if I should submit 
> > the
> > proposed changes in some other way.
> >
> > Regards,
> >
> > Ross Burnett 
>