Setting `org.gradle.jvmargs` property can lead to "Daemon disappeared" failures
When investigating reports of "daemon disappeared" in GitHub Actions, and [a feature request to address one cause](https://github.com/gradle/gradle-build-action/issues/122), it was found that the all of our DEFAULT_JVM8_ARGS are being lost as soon as _any_ value is set for `org.gradle.jvmargs`. When `org.gradle.jvmargs` is not set by the user, then the daemon will start with default values [specified here](https://github.com/gradle/gradle/blob/6ccf8a2cc74c8060992bd36189dec929143caed7/subprojects/launcher/src/main/java/org/gradle/launcher/daemon/configuration/DaemonParameters.java#L38-L39). But setting a value of `org.gradle.jvmargs` will overwrite these defaults, resulting in JDK defaults for `-Xmx`, `-Xms` etc. One of the key defaults set by Gradle is `-XX:MaxMetaspaceSize=256m`, which is required because [this value is unbounded on the JDK by default](https://docs.oracle.com/en/java/javase/17/gctuning/other-considerations.html#GUID-B29C9153-3530-4C15-9154-E74F44E3DAD9), allowing the Gradle daemon to consume more and more native memory until it crashes. This means that a user setting `org.gradle.jvmargs=-Xmx4g` can result in daemon crashes, unless the user knows that they must _also_ add a `-XX:MaxMetaspaceSize` setting. In a similar way, the `-XX:+HeapDumpOnOutOfMemoryError` default is lost when a user specifies `org.gradle.jvmargs`. ### Expected Behavior Important JVM defaults are not lost when a user sets unrelated JVM arguments. ### Current Behavior Users must b
Posted by bigdaz on Jan 28, 2022, 1:00 PM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
Setting `org.gradle.jvmargs` property can lead to "Daemon disappeared" failures
When investigating reports of "daemon disappeared" in GitHub Actions, and [a feature request to address one cause](https://github.com/gradle/gradle-build-action/issues/122), it was found that the all of our DEFAULT_JVM8_ARGS are being lost as soon as _any_ value is set for `org.gradle.jvmargs`. When `org.gradle.jvmargs` is not set by the user, then the daemon will start with default values [specified here](https://github.com/gradle/gradle/blob/6ccf8a2cc74c8060992bd36189dec929143caed7/subprojects/launcher/src/main/java/org/gradle/launcher/daemon/configuration/DaemonParameters.java#L38-L39). But setting a value of `org.gradle.jvmargs` will overwrite these defaults, resulting in JDK defaults for `-Xmx`, `-Xms` etc. One of the key defaults set by Gradle is `-XX:MaxMetaspaceSize=256m`, which is required because [this value is unbounded on the JDK by default](https://docs.oracle.com/en/java/javase/17/gctuning/other-considerations.html#GUID-B29C9153-3530-4C15-9154-E74F44E3DAD9), allowing the Gradle daemon to consume more and more native memory until it crashes. This means that a user setting `org.gradle.jvmargs=-Xmx4g` can result in daemon crashes, unless the user knows that they must _also_ add a `-XX:MaxMetaspaceSize` setting. In a similar way, the `-XX:+HeapDumpOnOutOfMemoryError` default is lost when a user specifies `org.gradle.jvmargs`. ### Expected Behavior Important JVM defaults are not lost when a user sets unrelated JVM arguments. ### Current Behavior Users must b
Comments (0)
No comments yet. Start the discussion.