jamesfredley commented on PR #16158: URL: https://github.com/apache/grails-core/pull/16158#issuecomment-5330424590
Follow-up landed in `0f5f5b653a` (pushed). What changed since the last description update: - **Proof the flag reaches forks.** Each of the three independent builds now has a forked-JVM test that fails if `-XX:ActiveProcessorCount` is missing and checks that `Runtime.availableProcessors()` matches it. Passed locally on root (`:grails-core:test`), `grails-gradle` (`:grails-gradle-plugins:test`), and `grails-forge` (`:grails-forge-core:test`). - **`grails-forge` CI fork cap.** Forge now uses the same `configuredTestParallel` formula as `grails-gradle` (`isCiBuild ? 3`, otherwise half the logical processors, still honouring `-PmaxTestParallel`). That was the last remaining consistency hole among the three builds. - **Documented the floor-of-2 vs `-PmaxTestParallel=1`.** A serial local run still advertises 2 processors to that one fork when `maxWorkerCount` is the unrestricted worker pool. Conservative and keeps G1; it is not a "give the fork the whole machine" switch. - **Windows JDK 25 shard 0.** The extra `groovydoc` / `installDist` work on that job runs in the Gradle daemon, which does **not** get `ActiveProcessorCount`. Those tasks cannot explain an APC regression. The remaining signal is cache-writer + full-`build` vs `testShard` workload, plus shard 0 tests seeing 2 processors instead of 4 (the expected 4x → 2x cost). Watching the next CI run; not reverting. Still out of scope: memory budget, 5 GB daemon on 7 GB macOS runners, Testcontainers-per-fork, and unbenchmarked `grails-gradle` / `grails-forge` full builds. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
