jvm arguments are not getting applied via command line parameter

[maxim-pandra]

I'm trying to profile a build with different -Xmx sizes. I'm using -D<key>=<value>: to override default heap settings. I assume it should work because of isssue https://github.com/gradle/gradle-profiler/issues/101

Unfortunately parameter does not getting applied.

I added jvmArguments logging to ToolingApiInvoker.java runTasks method.

Gradle plugin 5.4.1, MacOS

sampleProfile.scenarios

default-scenarios = ["incremental_build"]

incremental_build {
    tasks = ["assemble"]

    apply-abi-change-to = "app/src/main/java/com/example/myapplication/LongOperation.java"
    daemon = cold // value can be "warm", "cold", or "none"
    clear-build-cache-before = SCENARIO
    clear-transform-cache-before = SCENARIO
    show-build-cache-size = true
    #jvm-args = ["-Xmx2500m"]
}

---

First try with -D paramter gradle-profiler --benchmark --scenario-file ~/sampleProfile.scenarios --project-dir ~/AndroidStudioProjects/MyApplication/ --output-dir ~/tmp/1 incremental_build -Dorg.gradle.jvmargs="-Xmx2500m"

ToolingApiInoker runtasks() jvmArgs [-Xmx1536m, -Dfile.encoding=UTF-8, -Duser.country=RU, -Duser.language=en, -Duser.variant, -Dorg.gradle.jvmargs=-Xmx2500m, -Dorg.gradle.profiler.scenario=incremental_build, -Dorg.gradle.profiler.phase=WARM_UP, -Dorg.gradle.profiler.number=1, -Dorg.gradle.profiler.step=BUILD] And VisualVM shows that Xmx is default 1536

---

second try, with jvm-args in scenario gradle-profiler --benchmark --scenario-file ~/sampleProfile.scenarios --project-dir ~/AndroidStudioProjects/MyApplication/ --output-dir ~/tmp/2 incremental_build

ToolingApiInoker runtasks() jvmArgs [-Xmx1536m, -Dfile.encoding=UTF-8, -Duser.country=RU, -Duser.language=en, -Duser.variant, -Xmx2500m, -Dorg.gradle.profiler.scenario=incremental_build, -Dorg.gradle.profiler.phase=WARM_UP, -Dorg.gradle.profiler.number=1, -Dorg.gradle.profiler.step=BUILD] VisualVM shows that Xmx is applied and is Xmx2500m

I want to be able to change jvm arguments dynamically, so I can run script that will find optimal heap/workers combination. Looks like this is not currently possible due to a bug or unsupported feature.

[android10]

Hello! I'm also running into something similar. Override jvmargs does not work via the command line and I would like to pass these parameters depending on different running environments.

The general lifecycle of a Gradle build as follows, assuming we don't run it as a daemon:

1 - It launches as a new JVM process 2 - It parses the gradle.properties file and configures Gradle accordingly 3 - Next, it creates a Settings instance for the build 4 - Then, it evaluates the settings.gradle file against the Settings object 5 - It creates a hierarchy of Projects, based on the configured Settings object 6 - Finally, it executes each build.gradle file against its project

My assumption is that at the time I pass these parameters, the daemon is already running, for instance, the JVM process is already alive and not able to eat the passed arguments.

It makes sense just killing all gradle daemons (./gradlew --stop) and starting them with the new jvmargs

Can someone confirm this?

@maxim-pandra could you solve this issue?

[maxim-pandra]

@android10 What I end up doing, I patched ToolingApiInoker class, so it would remove "Dorg.gradle.jvmargs=" part, in case it found one.

The other solution is to generate a scenario file as needed since parameters from the scenario applied correctly.

A scenario file with multiple scenarios that differ only in jvm arguments is the easiest solution. You can run profiler with all such scenarios and get a pretty web page with results.

[android10]

@maxim-pandra thanks for that. In the end the assumptions of my previous comment were right. You can also fix the problem by stopping your gradle daemons and starting it like this:

./gradlew -Porg.gradle.jvmargs=-Xmx16g wrapper

[ultraon]

@android10 I see that you use -P in ./gradlew -Porg.gradle.jvmargs=-Xmx16g wrapper, but -P means gradle project property, using -D e.g. ./gradlew -Dorg.gradle.jvmargs=-Xmx16g wrapper means that the property will be used by gradle and jvm. I've tried with -D and works well.

[gabrielfeo]

I think this issue can be closed. The replies suggest profiler was re-using daemons from regular ./gradlew builds (not sure this was the behavior before), but the current behavior is profiler uses its own GRADLE_USER_HOME, so it doesn't share daemons with such builds. It also stops all of its own daemons before benchmarks. Thus I don't see how this could occur today.