Hi Erik,
On 26/08/2014 8:53 PM, Erik Joelsson wrote:
Hello,
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 ??
Thanks,
David
Bug: https://bugs.openjdk.java.net/browse/JDK-8056053
Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/
/Erik