RFR: JDK-8217728: Speed up incremental rerun of "make hotspot"

[Erik Joelsson]

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.

Webrev: http://cr.openjdk.java.net/~erikj/8217728/webrev.02/

/Erik

On 2019-04-02 14:26, Tim Bell wrote:
> Erik:
>
>> 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 
>> lookup.
>>
>> 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.
>
> Tim
>
>