RFR: 8201788: Number of make jobs wrong for bootcycle-images target (original) (raw)

Erik Joelsson erik.joelsson at oracle.com
Thu Apr 19 15:25:11 UTC 2018

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(if (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 ($(COMPILETYPE), cross) $(call LogWarn, Boot cycle build step 2: Building a new JDK image using previously built image) _+$(MAKE) (MAKEARGS)−f(MAKEARGS) -f (MAKEARGS)−f(TOPDIR)/make/Init.gmk PARALLELTARGETS=$(BOOTCYCLETARGET) _ - 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 ' 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 ". Thoughts? Suggestions? Thanks, Severin

More information about the build-dev mailing list