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

Tim Bell tim.bell at oracle.com
Wed Apr 3 22:00:11 UTC 2019

Even better.  Looks good.


On 04/03/19 14:20, Erik Joelsson wrote:
> 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

More information about the build-dev mailing list