-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b32
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8081982 | emb-9 | Erik Joelsson | P4 | Resolved | Fixed | b32 |
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.
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.
- backported by
-
JDK-8081982 Disable HOTSPOT_BUILD_JOBS when building with configure
-
- Resolved
-