Reducing build time by minimizing fork/exec and file system visits
Kelly.Ohair at Sun.COM
Mon Oct 5 23:35:11 UTC 2009
This is kind of an update on the bug that started out as:
6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building)
But that bug has been closed as a fix to just the corba repository
Makefiles. So if and when these changes are pushed in, the bugid will
be different, or it may appear as multiple bugids and changesets.
Is my current state for the jdk repository Makefiles.
The fork/exec reduction is pretty significant, over 50% reduction as
measured on Solaris builds, but the goal of significantly improving
the overall Windows CYGWIN build time is less fruitful, maybe a 10-15%
reduction in build time.
This is not at all the same results as I saw with the corba repository
makefile changes. I was going to post some build time data, but it's
hard to be accurate, with Windows in particular.
The environment variables are effectively being used as a sort of
cache of information with these changes. Plus the number of 'find'
commands has been limited.
The above webrev includes a few diversions to the primary change:
* All source files that were template java files, used to generate
java source files were renamed *.java-template. This file suffix
change simplifies much of the Makefile logic and could probably
be done as a separate changeset.
* Use of the make syntax $(eval) required an upgrade to make 3.81, and
this upgrade brought out a problem with make 3.81 and MKS shells
regarding escaped quotes on compile lines. So you will see changes
from things like -DX="\"Y\"" to -DX='"Y"', to avoid the problem,
but that makes it the same for all platforms, a good thing.
The old make 3.78.1 (or < 3.81) and MKS shells seem happy with
either way. These changes could probably be done with a separate
* Use of AUTO_JAVA_PRUNE had to become more specific because of the
use of the make $(filter*) functions rather than SED and GREPs.
This makes the act of pruning more explicit.
I'm not sure where to go from here, it's obvious that the low hanging
fruit that I thought would help here is not helping that much.
At this point, internally, at least for Windows X64, we will probably
continue to use MKS, perhaps just build with CYGWIN on 32bit Windows?
Advice, ideas, or suggestions are welcome.
More information about the build-dev