RFR: JDK-8217728: Speed up incremental rerun of "make hotspot"
erik.joelsson at oracle.com
Wed Apr 3 21:20:10 UTC 2019
I discovered in issue with this patch. If the build is run in a very
long directory path, the cat command line for combining the *.d files
can get too long and hit the command line limit. I've fixed this by
CDing into the directory and listing the files with a relative path instead.
I also discovered that I had missed replacing a $1_DEP variable
reference with $1_DEPS_FILE. When fixing this I decided to apply this
new name standard universally in NativeCompilation.gmk, so now
$1_PCH_DEP and $1_RES_DEP and friends have also been renamed.
On 2019-04-02 14:26, Tim Bell wrote:
>> This patch improves general incremental build performance of native
>> binaries, which in particular improves performance for rebuilding
>> hotspot. Specifically it removes overhead in the make file processing.
>> Two major issues are addressed:
>> 1. Long ago, I had managed to introduce an O(n^2) construct when keeping
>> track of which object files have already been processed. This is used to
>> support overriding shared files with platform specific (or open/custom).
>> Basically the first file with a specific name takes precedence over any
>> other files with the same name. Changed this to a simple variable
>> 2. For each compilation unit, we have the compiler generate make
>> dependency files to help correctly build incrementally on the next make
>> invocation. When there are many compilation units, there will be a lot
>> of these files, so opening and parsing each file takes time. I've added
>> an additional step where all of these file are concatenated at the end
>> so that the next make invocation only needs to open one single file
>> (with a fallback to reading the individual files for robustness).
>> Combining the files also allows for removing a ton of duplicate
>> information with "sort -u".
>> I'm also fixing the hotspot-only and hotspot-<variant>-only top level
>> targets (in Main.gmk) which I discovered weren't functioning while
>> testing the changes.
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217728
>> Webrev: http://cr.openjdk.java.net/~erikj/8217728/webrev.01
> Looks good.
More information about the build-dev