Hello Severin,
The suggested patch is not a good idea because by setting -j on the make
command line in a sub make disables the job server. The job server is
what makes it possible to do recursive make with a fixed global number
of "jobs". If you do as you suggest, you essentially double the total
number of available "jobs". The original make retains its number and the
submake get a full other set of the same number of "jobs".
My suggestion was to explicitly turn off the setting of JOBS based on a
special variable flag, just for bootcycle builds. Magnus didn't like
that because introducing a lot of special flags everywhere will
eventually lead to very convoluted code. He instead suggested that the
bootcycle call should continue to set JOBS to empty, then the code in
Init.gmk which sets the -j flag should be changed to:
$(if $(JOBS), -j=$(JOBS))
So that we only set -j if JOBS have a value. My only objection to that
was that we then no longer support the case of letting make run with any
number of jobs. I do agree that removing that option isn't a big deal.
You can always work around it by setting JOBS to a very large number
(like 1000, which is way more than any possible concurrency currently
possible in the build anyway).
So to summarize, I think the correct solution to the bug is the snippet
above.
/Erik
On 2018-04-19 07:46, Severin Gehwolf wrote:
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8201788
I'd like to get a fix in for an old discussion which already happened a
while ago:
http://mail.openjdk.java.net/pipermail/build-dev/2017-April/018929.html
The issue is that for bootcycle-images target a recursive call to make
is being called with 'JOBS=""' which results in a call to "make -j".
Thus, make is free to use as many jobs as it would like. This may cause
for the occasional build failure. It has for us in the past.
In this old thread above a patch like this was discouraged, unless I
misunderstood something.
diff --git a/make/Main.gmk b/make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -321,7 +321,7 @@
ifneq ($(COMPILE_TYPE), cross)
$(call LogWarn, Boot cycle build step 2: Building a new JDK image
using previously built image)
+$(MAKE) $(MAKE_ARGS) -f $(TOPDIR)/make/Init.gmk
PARALLEL_TARGETS=$(BOOTCYCLE_TARGET) \
- JOBS= SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
+ JOBS=$(JOBS) SPEC=$(dir $(SPEC))bootcycle-spec.gmk main
else
$(call LogWarn, Boot cycle build disabled when cross compiling)
endif
It's my understanding that such a fix would pass down the relevant JOBS
setting to sub-make and, thus, producing the desired 'make -j <JOBS>'
call? What am I missing? If somebody wants to shoot themselves in the
foot by doing:
configure ...
make JOBS=
That should be fine as it would just result in "make -j" calls without
arguments. The common case where the JOBS setting comes from configure
would be fixed, though. bootcycle-images target would result in "make
-j <num-cores>".
Thoughts? Suggestions?
Thanks,
Severin
