jamesfredley commented on PR #16167: URL: https://github.com/apache/grails-core/pull/16167#issuecomment-5541292446
Looked at this independently against the workflow, `build.gradle` / `gradle/test-config.gradle` / `CompilePlugin`, current runner specs, and the #16235 logs — not from the review text. **Mechanics.** Confirmed: `-PmaxTestParallel` feeds `configuredTestParallel`, CI test forks are 768m, and with `org.gradle.parallel=true` the live fork count is bounded by `--max-workers` (CPU count), not by `maxParallelForks`. Compiler forks are a separate `-Xmx2G` in CompilePlugin; the `gradle.properties` comment already excludes them from the simplified floor. **The Groovy 5.1.1 OOM is a different bug.** `8.0.x` is still on Groovy 5.1.0. This PR opened 2026-08-18; #16235 is later. I pulled run 33062440061: the failures are `java.lang.OutOfMemoryError: Java heap space` inside the Gradle daemon (`groovydoc` on Forge, then a cascade of `jacocoTestReport` on Grails-Core) on Ubuntu (16 GB), Windows, **and** macOS. A macOS-only `--max-workers` cap cannot fix a 5G daemon that OOMs on a 16 GB machine. That is apache/groovy#2840 or a daemon `-Xmx` bump — not this change. sbglasius linking the two PRs mixed them. **The cap stays.** `macos-latest` is still 3 CPU / 7 GB per current GitHub-hosted runner specs. Without the cap the configured floor is still `5G + 3x768m = 7.25G`, which does not fit. That is runner RAM for concurrent child JVMs, independent of Groovy 5.1.1's in-daemon heap regression. Green macOS jobs on 5.1.0 do not make the budget arithmetic wrong; they mean RSS is usually under the `-Xmx` ceilings. The yml comment already says this reduces pressure rather than proving a fit. Merged current `8.0.x` onto the branch. -- 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]
