RFR: JDK-8056053: Disable HOTSPOT_BUILD_JOBS when building with configure
david.holmes at oracle.com
Tue Aug 26 12:09:18 UTC 2014
On 26/08/2014 8:53 PM, 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.
I don't know how make handles -j propagation but from your description
it sounds like we will still generate too much concurrency as the
submakes will be run with the same -j value as the top-level. ??
I'm also unclear how we used to pass HOTSPOT_BUILD_JOBS and didn't need
.NOTPARALLEL, but now we pass -j from the top we do need .NOTPARALLEL ??
> 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