jamesfredley opened a new pull request, #16167: URL: https://github.com/apache/grails-core/pull/16167
## What Make the CI memory budget explicit, and stop the macOS runner from being over-committed. `org.gradle.jvmargs` sizes the **Gradle daemon** only. Test forks are separate child JVMs and take their heap from `maxHeapSize` in `gradle/test-config.gradle`. Those two numbers are set in different files and have never been reasoned about together, so nothing stops their sum from exceeding the runner. The real peak of a CI job is: ``` daemon -Xmx + (concurrent test forks x per-fork maxHeapSize) + OS ``` The number of *concurrent* forks is **not** `maxParallelForks`. With `org.gradle.parallel=true` several `Test` tasks run at once, each entitled to its own forks, so the true bound is Gradle's global worker pool (`--max-workers`, defaulting to the CPU count). Against the [GitHub-hosted runner specs](https://docs.github.com/en/actions/reference/runners/github-hosted-runners): | Runner | CPU | RAM | Default workers | Worst-case peak | |---|---|---|---|---| | `ubuntu-latest` / `windows-latest` | 4 | 16 GB | 4 | 5G + 4x768m = 8.0 GB | | `macos-latest` (M1) | 3 | 7 GB | 3 | 5G + 3x768m = 7.25 GB | Linux and Windows have the headroom. macOS does not: the worst case exceeds the machine. ## Change - `.github/workflows/gradle.yml`: the macOS entry - and only that entry - now passes `-PmaxTestParallel=2 --max-workers=2`, via a new `runner_arguments` matrix key that is empty for every other entry. Capping `--max-workers` is the part that actually bounds concurrent forks; `-PmaxTestParallel` alone would not, for the reason above. New peak: `5G + 2x768m = 6.5 GB`, which fits in 7 GB. - `gradle.properties`: document the arithmetic next to `org.gradle.jvmargs`, including the daemon-vs-fork distinction and the worker-pool bound, so the next person changing either number can see both sides of the budget. The daemon stays at 5 GB deliberately: `groovydoc` is what needs it, and shrinking it would trade a memory problem for a slower build. ## Why draft The macOS runner has 3 CPUs, so going from 3 workers to 2 will cost some wall-clock on that job. That trade is worth discussing, and the alternative - a smaller daemon plus more workers - is worth measuring rather than assuming. Opening as a draft to get that decision made before it lands. ## Scope - No test is added, removed, skipped, or weakened. This changes concurrency only, not which tests run. - No other runner changes behaviour: `runner_arguments` is undefined (empty) for the Ubuntu and Windows entries. - `grails-gradle` and `grails-forge` are separate Gradle builds with their own daemon settings and are **not** touched here. ## Verification - `./gradlew validateActions help -PmaxTestParallel=2` - BUILD SUCCESSFUL, "Checked 24 workflow file(s) - all compliant". ## Related Follow-up to #16158, which capped the CPUs a forked test JVM believes it has. That PR deliberately changed CPU only; this one is the separate memory question it named as out of scope. -- 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]
