jdaugherty opened a new pull request, #16376: URL: https://github.com/apache/grails-core/pull/16376
The macOS CI job fails with java.lang.OutOfMemoryError in the documentation chain about one run in four. The cause is not the runner: every groovydoc task defines the Groovy `groovydoc` Ant task against a per-project AntClassLoader inside the daemon, and that loader - with the whole Groovy runtime and its unbounded ANTLR parser caches behind it - stays reachable from `project.ant` for the rest of the build. Documenting 125 modules therefore leaves 125 Groovy runtimes live in one heap. Reproduced on a 128 GB machine: `./gradlew groovydoc --rerun-tasks --max-workers=2` on the 5 GB daemon does 64 Full GCs, ends holding 4.9 GB after a Full GC, and Gradle itself reports "Daemon will be stopped at the end of the build after running out of JVM heap space" - with no tests, no aggregate groovydoc and no guide in the graph. aggregateGroovydoc (~1.9 GB) and publishGuide, which starts a JRuby runtime for AsciidoctorJ, then run on whatever is left, which is why the OOM lands in publishGuide. Each groovydoc task now runs in a JVM of its own, launched by GroovydocRunner with only the groovydoc tooling and the documented module's classpath on it. That JVM exits when the task does, and the framework's Groovy is the only one present - inside Gradle, and inside a Gradle worker process too, the older Groovy that build logic runs on wins the classloader lookup and generates visibly poorer documentation. PublishGuideTask hands the guide to a worker process the same way; its body moves to UserGuideBuilder, which is free of Gradle types and can be tested directly. The daemon heap drops from 5G to 3G as a result. Verified on the same machine: the full groovydoc run now does zero Full GCs and peaks at 1.5 GB in a 2 GB daemon, and `:grails-doc:docs :grails-doc:auditGroovydocLinks --rerun-tasks` in a 3 GB daemon produces byte-for-byte identical output - all 5173 aggregate API pages and all 741 guide files - with zero Full GCs. -- 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]
