You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After addressing OutOfMemoryErrors in org.gradle.profiler.Main by raising the max heap via GRADLE_PROFILER_OPTS (see #512), I started hitting them in the org.gradle.launcher.GradleMain processes when running scenarios with run-using = cli.
I tried to use GRADLE_OPTS to set the -Xmx for those, but observed via VisualVM that it was not having any effect. I then tried with JAVA_OPTS. That worked, though I did observe that both the default -Xmx64m and my JAVA_OPTS setting of -Xmx640m were present in the listed JVM args. I could see via the VisualVm Monitor tab that my -Xmx640m setting was the one in use, and that addressed my OutOfMemoryErrors for the Gradle Launcher processes.
I'm not familiar with the history behind or difference between the usage of both GRADLE_OPTS and JAVA_OPTS, but the latter seems an overly broad naming choice. I'd guess GRADLE_OPTS to be the preferred option, so it would be nice if that worked for Gradle Launcher processes executed by the Gradle Profiler. Or, if JAVA_OPTS is the correct or preferred choice, it would helpful if some documentation were added to the README to explain that.
The text was updated successfully, but these errors were encountered:
ianbrandt
changed the title
GRADLE_OPTS not being used with run-using = cliGRADLE_OPTS not being used with run-using = cliOct 16, 2023
@asodja, Thank you for replying. I hadn't tried jvm-args, as I presumed it would set the -Xmx for the Gradle Daemon process, not the Gradle Launcher process. I've tested it now, and that indeed seems to be how it works. The value ends up in the Gradle Launcher's -Dorg.gradle.jvmargs argument, and becomes the max heap setting for the launched Gradle Daemon process, but the Gradle Launcher process itself remains at the default -Xmx64m.
After addressing
OutOfMemoryError
s inorg.gradle.profiler.Main
by raising the max heap viaGRADLE_PROFILER_OPTS
(see #512), I started hitting them in theorg.gradle.launcher.GradleMain
processes when running scenarios withrun-using = cli
.I tried to use
GRADLE_OPTS
to set the-Xmx
for those, but observed via VisualVM that it was not having any effect. I then tried withJAVA_OPTS
. That worked, though I did observe that both the default-Xmx64m
and myJAVA_OPTS
setting of-Xmx640m
were present in the listed JVM args. I could see via the VisualVm Monitor tab that my-Xmx640m
setting was the one in use, and that addressed myOutOfMemoryError
s for the Gradle Launcher processes.I'm not familiar with the history behind or difference between the usage of both
GRADLE_OPTS
andJAVA_OPTS
, but the latter seems an overly broad naming choice. I'd guessGRADLE_OPTS
to be the preferred option, so it would be nice if that worked for Gradle Launcher processes executed by the Gradle Profiler. Or, ifJAVA_OPTS
is the correct or preferred choice, it would helpful if some documentation were added to the README to explain that.The text was updated successfully, but these errors were encountered: