RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
erik.joelsson at oracle.com
Wed Aug 27 12:53:52 UTC 2014
Thanks David and Magnus for the reviews!
Now for pushing this. The changes in root and hotspot need to go
together. They should not affect the standalone hotspot build, nor the
resulting built bits. I think it is safe to push both to jdk9/hs-rt as
it would not affect testing compatibility with the promoted jdk build.
Is it ok to do so?
On 2014-08-26 12:53, Erik Joelsson wrote:
> Please review this proposed fix for the Hotspot build.
> In the new jdk9 build, we utilize the gnu make job server, which
> automatically makes sure the -j flag gets propagated and shared
> between all recursive make calls. In the hotspot build, this gets
> overridden by the HOTSPOT_BUILD_JOBS variable. Configure estimates a
> reasonable number of parallel make jobs into the JOBS variable, which
> gets propagated to the HOTSPOT_BUILD_JOBS variable. This used to work
> well enough, but in the new build, the hotspot build is happening
> concurrently with other parts of the build and the consequence is that
> the hotspot build gets JOBS number of jobs and the rest of the build
> also gets JOBS number of jobs, all of which are used at the same time.
> We would like the whole build to share in the same job pool.
> To fix this, the setting of -j$(HOTSPOT_BUILD_JOBS) needs to be made
> conditional and we need to add .NOTPARALLEL: to a number of makefiles
> in hotspot that currently can't handle being executed in parallel.
> Lastly, the + sign must be added first to recipe lines that call make
> recursively but are not explicitly using the MAKE variable directly.
> The result will be that the active -j flag in the root makefiles will
> just automatically propagate down to the hotspot makefiles.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056053
> Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/
More information about the build-dev