On 8/27/14 6:53 AM, Erik Joelsson wrote:
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?
Not only OK, but also the preferred way to go! Alejandro prefers that
HotSpot makefile changes come up through HotSpot repos so we don't
get any surprises...
Dan
/Erik
On 2014-08-26 12:53, 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.
Bug: https://bugs.openjdk.java.net/browse/JDK-8056053
Webrev: http://cr.openjdk.java.net/~erikj/8056053/webrev.01/
/Erik
