Run application via gradlew with -Xmx and -Xms

Question

I have an application. I run it via

gradlew run-app

Or debug

gradlew debug-app

It works. How do I pass '-Xmx' argument into the application which I run (debug)? Is it possible to do so without edditing build.gradle file?

I found this Gradle unknown command-line option '-X'

I get a similar error when I try

gradlew debug-app -Xmx2000m

Error

FAILURE: Build failed with an exception.

* What went wrong:
Problem configuring task :debug-app from command line.
> Unknown command-line option '-X'.

---

I tried to create a file gradle.properties in GRADLE_USER_HOME directory (by default, it is USER_HOME/.gradle).

org.gradle.jvmargs=-XX\:MaxHeapSize\=4256m -Xmx4256m -Xms2000m

I also tried to org.gradle.jvmargs=-Xmx2000m in project folder gradle.properties.

And even then when I run an application, I see Commited Memory size is < 520 MiB

And this is when I run it as a normal Java App

In the second case, when I run the application as a normal Java app with -Xms, -Xmx, Commited Memory size is about 3.5 GiB because I passed -Xmx4512m -Xms2512m parameters.

Seleta

I edited my answer – Registrant

Answer 1

Add this in your gradle.properties file :

org.gradle.jvmargs=-Xmx2000m

From here

org.gradle.jvmargs

Specifies the jvmargs used for the daemon process. The setting is particularly useful for tweaking memory settings. At the moment the default settings are pretty generous with regards to memory.

edit : my answer what about the gradle daemon jvm, not the app jvm. You have to use the jvmArgs property

The extra arguments to use to launch the JVM for the process. Does not include system properties and the minimum/maximum heap size.

Registrant

What does org.gradle.jvmargs=-Xms1024m -Xmx1024m -Xss1M -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 mean in the gradle.properties – Seleta

It sets specific jvmargs for the daemon process – Registrant

also note that if you're using 32bit jdk you can only set the heap space to max 4g (on windows 2g). In my case gradle couldn't startet a new gradle daemon because I was using 32bit jdk and I set the heap space too large. – Clammy

Or on command line: ./gradlew -Dorg.gradle.jvmargs=-Xmx4g ... – Messenger

Answer 2

Firstly, thanks @ToYonos for leading me to the right direction.

Secondly, I found the solution here https://mcmap.net/q/355529/-how-to-run-jetty-via-gradle-in-debug-mode. I ran my app from command line.

set GRADLE_OPTS=-Xms1724m -Xmx5048m
gradlew debug-app

Note, CMD Windows command SET works locally, so if you close your terminal, GRADLE_OPTS will not be set. For Linux, you can use

export GRADLE_OPTS=WHATEVER

This is what I wanted to achieve.

Seleta

One liner (Linux, at least): GRADLE_OPTS="-Xms1724m -Xmx5048m" ./gradlew debug-app – Wonderstricken

GRADLE_OPTS="-Dorg.gradle.jvmargs='-Xms4g'" it should be like this actually – Ownership

Answer 3

Using application plugin one can use applicationDefaultJvmArgs property

apply plugin: 'application'    
applicationDefaultJvmArgs = ["-Xms1024m", "-Xmx2048m"]

The arguments will be applied to run task and to start script of your application

more info

County

Thanks, it is also nice. However, one drawback. What if in debug I want to run with command line arguments, and in deployment mode I don't need command line arguments. I prefer not putting extra lines of code into production / deploy mode. – Seleta

You can use ${System.env.VAR_NAME} by configuating of applicationDefaultJvmArgs. Due the limitation of plugin the variables have to be converted before run. See this comment https://mcmap.net/q/355530/-gradle-application-plugin-and-system-environment-variables. – County

Answer 4

Unfortunately gradle doensn't honor applicationDefaultJvmArgs in 7.x branch.

As a workaround you can use following code (gradle.kts version, groovy version pretty similar):

tasks.withType<JavaExec>().configureEach {
  jvmArgs = listOf("-Xms1g", "-Xmx2g")
}

Retributive

Answer 5

In my case Invalidate cache and restart the android studio(which is automatically restarted) then the error will be gone after restarting the android studio

then

Adjournment