On Fri, 19 Dec 2025 18:29:43 GMT, Kevin Rushforth <[email protected]> wrote:
> This PR adds a new `MAX_COMPILE_THREADS` gradle property to to limit the > number of build-time parallel compilation threads to the smaller of this > property and the number of avialable processors. > > Our gradle build spawns up to `NUM_COMPILE_THREADS` compilation tasks in > parallel when building native libraries. By default, `NUM_COMPILE_THREADS` is > set to the value returned by `Runtime.getRuntime().availableProcessors()`. > That value can be overridden on the command line by setting the > `NUM_COMPILE_THREADS` gradle property. We need a way to clamp > `NUM_COMPILE_THREADS` at some maximum value without the caller having to > compute it. > > The change in `build.gradle` is simple: > > * Define a new `MAX_COMPILE_THREADS` gradle property, which will default to 0 > (meaning unlimited) for compatibility with current behavior. > > * Set the default value of `NUM_COMPILE_THREADS` as follows: > > > NUM_COMPILE_THREADS = MAX_COMPILE_THREADS > 0 > ? Math.min(MAX_COMPILE_THREADS, availableProcessors) > : availableProcessors( > > > This will allow a test scripts that runs on a number of different platforms > to clamp to a maximum value without having to use jshell or similar to > implement `Math.min(MAX_COMPILE_THREADS, > Runtime.getRuntime().availableProcessors())` in the script. > > We have a practical need for this in our headful test systems, several of > which report a higher number of processors than they can effectively support. > Without clamping, the build will either run slower (due to too much swapping) > or fail altogether when building WebKit. lgtm... ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/2014#pullrequestreview-3602965882
