Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRADLE_OPTS not being used with run-using = cli #513

Open
ianbrandt opened this issue Oct 16, 2023 · 2 comments
Open

GRADLE_OPTS not being used with run-using = cli #513

ianbrandt opened this issue Oct 16, 2023 · 2 comments
Labels

Comments

@ianbrandt
Copy link

ianbrandt commented Oct 16, 2023

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.

@ianbrandt ianbrandt changed the title GRADLE_OPTS not being used with run-using = cli GRADLE_OPTS not being used with run-using = cli Oct 16, 2023
@asodja
Copy link
Member

asodja commented Oct 16, 2023

Does it work if you pass jvm-args for your scenario?

@ianbrandt
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants