A modern programming language that makes developers happier.

kotlinlang

Can anybody tell me how to run unit tests in a compose desktop project with more than `512m` of memory? All my configuration attempts seem to be consistently ignored. I added `-Xmx4096m` to the runtime configuration of the test, `org.gradle.jvmargs=-Xmx4g` to gradle.properties and more but my test always ends with an OutOfMemoryError which is no surprise because a printout like this inside the test code

```        val env = Runtime.getRuntime()
        println("Max Heap Size = maxMemory() = " + env.maxMemory()) //max heap size from -Xmx, i.e. is constant during runtime```
always tells me that the test is running with just `512m`. I have the feeling that this `512m` limit is somewhere just hard coded and overwrites all external settings. Is that possible?

You could use this in your `build.gradle.kts`:
```tasks.withType&lt;Test&gt;().configureEach {
    maxHeapSize = "8G"
}```

Great. That worked. Thank you very much but can you tell me why setting it, e.g., in the runtime configuration as advertised does not work?

`org.gradle.jvmargs` just configures the Gradle build. A test task spawns a separate JVM which uses its own configuration.

And the *Run/Debug Configuration* of the corresponding test? Even the example under VM options explicitly mentions setting -Xmx2048m but it is ignored. I just find that confusing.

I’ve never tried to configure the option outside of a build script, but yes, there are so many parts interacting with each other that things easily become confusing.

Gradle test execution is actually <https://docs.gradle.org/current/userguide/java_testing.html#sec:test_execution|documented here>. It says:
&gt; Gradle executes tests in a separate ('forked') JVM, isolated from the main build process. This prevents classpath pollution and excessive memory consumption for the build process. It also allows you to run the tests with different JVM arguments than the build is using.
The <https://www.jetbrains.com/help/idea/2023.1/run-debug-gradle.html#add_advanced|IntelliJ documentation> is somewhat vague, talking about VM options being "passed to the Java virtual machine when launching the application". In this case, "launching the application" probably means "invoking Gradle", so it would always configure just the Gradle build, never an out-of-process test execution.

The same seems to apply in a similar way to the various main program executions as well which are also executed via Gradle but are not tests.

Yes, depending on the Gradle plugin used. The `application` plugin says that its `run` task will
&gt; launch a new JVM with its classes
So the IntelliJ IDEA doc could be more specific to account for typical Gradle JVM use cases.