Colin
March 22, 2023, 4:00pm
6
Hey all.
I found this issue on Gradle’s side:
opened 01:00PM - 28 Jan 22 UTC
in:daemon
a:bug
When investigating reports of "daemon disappeared" in GitHub Actions, and [a fea… ture 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 be aware of all important JVM argument defaults, and include all of these when setting any values for `org.gradle.jvmargs`.
### Context
This was discovered when investigating "daemon disappeared" issues in GitHub Actions workflows.
Here is an example of a build with such a failure: https://github.com/androidx/androidx/runs/4971463356?check_suite_focus=true#step:10:3845. No build scan was captured due to the nature of the failure.
Daemon log file for that CI run:
[gradle-daemon-logs_room.zip](https://github.com/gradle/gradle/files/7958782/gradle-daemon-logs_room.zip)
This part seemed important:
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 , 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.
@Shudy To start – can you try adding -XX:MaxMetaspaceSize=256m?
1 Like