parpavm / bytecodeparser

[Dave Dyer]

Spurred by the current IOS build crisis, I took a look at parpavm / bytecodeparser as it
builds my project.  Here are a few points I noted.

1) it is indeed close to the 256m memory usage set by your current build, which seems bizarre, but
no one ever claimed java was memory efficient.  Steve's increase to 384m ought to dig out of the
current problem.

2) the output directory is also an input directory, read by "readNativeFiles" so if it is not initially clean, bad things will happen.
I would make sure the output directory is always a new directory.  I suppose your overall build process is supposed to create
a unique output directory for the build, but defense in depth is best.   Some of the past random failures of the build process
may have been due to dirty output directories, but I can't be sure as the evidence is gone.

3) a huge percentage of the time is spent in eliminateUnusedMethods(), which I would expect would usually accomplish
very little.  This could benefit from a "fast build" switch.  I bet you could cut my build time to 5 minutes.
eliminateUnusedMethods seems to be a N^2 process that thrashes the GC by creating lots and lots of strings.  It
would be worthwhile to optimize it.

4) for other reasons I haven't determined, the memory usage spikes at the end, which accounts for the heartbreaking
current behavior of crunching for 20-30 minutes and then failing with out of memory error. See figure at the top.

[Dave Dyer]

More observations.

While there is no harm in overgenerous memory allocations, there IS harm in stingy ones. When the application
size gets within shouting size of the limit, there's a possibility of a GC disaster which stretches the runtime and
still may or may not allow the build to succeed. Here's an example.
My trial build with a 256M limit took 1386 seconds in the cull phase.

Whereas the same run, with a 384M limit, takes only 300 seconds in the cull phase.