On Mon, 2 Sep 2024 07:20:50 GMT, Johan Vos <j...@openjdk.org> wrote: > When building webkit, the perl script in > `modules/javafx.web/src/main/native/Tools/Scripts/build-webkit` will check > for a `-j` argument in `$makeArgs`. If that doesn't exist, it will default to > `numberOfCPUs()`. > This PR passes the `NUM_COMPILE_THREADS` from `build.gradle` to the > `build-webkit` script. When not setting `NUM_COMPILE_THREADS` explicitly,it > will default to the number of CPU's as well, hence it will have the same > behavior as without this PR. > When setting `NUM_COMPILE_THREADS` explicitly, the provided number will be > used by cmake as well now.
Here are the numbers for our CI build with / without the patch: OS / Arch|Current|This PR ---------|-------|------- macOS / aarch64|13m:41s|56m:36s macOS / x64|28m:30s|2h:24m:52s To answer your question: > I read the cryptic comment in build.gradle `// On Mac we limit it to 1 by > default due to problems running gcc in parallel` What is the problem that is > being referred to here? And why would that problem occur in the other native > compile jobs but not in the (resource intensive) webkit compile jobs? That was added for this bug: [JDK-8094590](https://bugs.openjdk.org/browse/JDK-8094590): Mac: Intermittent build failures in task graphics:ccMacFontT2K When I "fixed" that bug (workaround, really) by disabling parallel compilation on macOS, I filed the following as a follow-up, but never got to it: [JDK-8089417](https://bugs.openjdk.org/browse/JDK-8089417): Mac: intermittent T2K gcc failure prevents parallel compilation It's quite possible that this was a bug in the Xcode gcc compiler, and if so, would be no longer relevant. Xcode switch from gcc to clang a long time ago. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1554#issuecomment-2326872149
