sbglasius commented on code in PR #16376: URL: https://github.com/apache/grails-core/pull/16376#discussion_r4073226151
########## gradle.properties: ########## @@ -96,8 +93,23 @@ org.gradle.daemon=true # other native memory, the Gradle client, and forked Java/Groovy compiler workers (which # CompilePlugin gives their own -Xmx2G). Treat it as a floor when sizing a runner. # -# On the 4-CPU / ~16 GB Linux and Windows runners that floor is 5G + 4x768m = 8G, which -# fits. On the 3-CPU / ~7 GB macOS runner it is 5G + 3x768m = 7.25G, which does not - so -# .github/workflows/gradle.yml caps --max-workers there to reduce memory pressure, rather -# than shrinking this daemon and slowing groovydoc. -org.gradle.jvmargs=-Dfile.encoding=UTF-8 -Xmx5G +# Documentation does NOT run on this heap. Every groovydoc task is launched as a JVM of its +# own by GroovydocEnhancerPlugin, and the user guide in a worker process by PublishGuideTask. +# That is what lets this number be 3G: before, groovydoc kept a Groovy runtime per documented +# module alive inside the daemon for the whole build, which needed 5G and still exhausted it +# on the smallest runner. +# +# 3G is measured, not guessed. `build :grails-shell-cli:installDist groovydoc -PskipTests +# --max-workers=2` - 3253 tasks, the macOS job's graph without test execution - runs it with +# ZERO full GCs; mixed collections settle the daemon at about 2.0 GB throughout. Re-measure +# with -Xlog:gc* before changing it, and read the MIXED collections: a young-only "after GC" +# figure does not touch the old generation and reads about 700 MB higher than the truth. +# Raising this on a memory-constrained runner can backfire - a larger heap lets G1 defer +# collection, so the daemon's resident size grows to meet it and leaves the forked doc JVMs +# and test forks less room, not more. +org.gradle.jvmargs=-Dfile.encoding=UTF-8 -Xmx3G Review Comment: Resolved by @jdaugherty's [measurement](https://github.com/apache/grails-core/pull/16376#issuecomment-3699999999): `build :grails-shell-cli:installDist groovydoc --continue -PonlyCoreTests -PskipCodeStyle --max-workers=2 -PmaxTestParallel=2` - 123 groovydoc tasks, both aggregates, the guide and 108 test tasks in one daemon, 0 Full GCs, mixed collections settling at ~1.68-1.77 GB of 3G. That is the macOS job's command line exactly (`.github/workflows/gradle.yml:205-211` adds `-PonlyCoreTests -PskipCodeStyle` to `matrix.gradle_task`), so the specific gap I raised - test execution absent from the evidence - is closed with the real flag set rather than an approximation. On @matrei's related caveat about Checkstyle/PMD/CodeNarc still running in-daemon: every job in `gradle.yml` passes `-PskipCodeStyle`, and `codeStyle` runs in `.github/workflows/codestyle.yml` as its own workflow - a separate daemon whose graph has no groovydoc, no guide and no tests. So that analysis never shares a daemon with the documentation chain on CI. It does still share one for a plain local `./gradlew build`, which is where the 3G floor is least proven. The point I'd keep, and it's @matrei's rather than mine, is the sample size: peak used was 2827M of 3072M, and the original failure was ~1 in 4 runs. One green macOS run isn't proof at that rate. Resolving this thread - the measurement gap is answered. -- 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]
