How to decrease Gradle JUnitRunner memory consumptions?

This question is follow up for this question http://stackoverflow.com/questions/20490105/gradleworkermain-outofmemoryerror I have module with 282 tests - working with inmemory db, CRUD operations. H2 and HSQL give the practically equal results in memory consumptions. If I use netbeans RCP ant task for testing this module I see 540MB max memory consumptions. I couldn’t take profiler snapshot as I see ant task use JUnitRunner for each test class. That why I can’t catch this JVM in profiler. Next picture is system memory consumption for ant junit task https://dl.dropboxusercontent.com/u/8384811/Misc/ant-unit-test.jpg

If I use gradle test task for the same module I may get different exceptions for not enough memory reason like this http://pastebin.com/ndYj1gr4 and JVM crush like this http://pastebin.com/5pRRxMHC (4GB Xmx is not enough). If I’m lucky and close all programs on my machine with 8GB RAM I may see the next picture during gradle junit testing for the same module. https://dl.dropboxusercontent.com/u/8384811/Misc/gradle-unit-tests.jpg

So how I can set the gradle test task running JUnitRunner separately against the test class for all module instead off one JUnitRunner for whole test classes in modules. Or can you suggest me another way for decreasing memory consumptions.

The second question. Could you explain difference in network history for gradle vs ant unit test tasks? I swear that I don’t downloading anything during test running.

Hey,

You might use test.forkEvery setting to recycle worker processes.

It would be very helpful if you dig a bit more and profile the Gradle’s test task behavior for your case, looking for memory hotspots. It’s hard to say why it needs more memory than the ant task.

Hope that helps!

test {

forEvery = 0

maxParallelForks = 2

}

will result in http://pastebin.com/J40h0V1M

It’s similiar to http://forums.gradle.org/gradle/topics/strange_exception_thrown_running_unit_tests http://issues.gradle.org/browse/GRADLE-2759 And this is not due using System.exit()

test {

forEvery = 3

maxParallelForks = 1

} resulted in JVM crush http://pastebin.com/eNgbNAXr

When gradle engineer solved the bug GRADLE-2759 did he/she check the reason for the next exception?

org.gradle.messaging.remote.internal.MessageIOException: Could not read message from ‘/0:0:0:0:0:0:0:1:53248’.

at org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:88)

I’m already asked about enourmous network activity during gradle unit testing. How could you explained it? Please see to https://dl.dropboxusercontent.com/u/8384811/Misc/network%202.jpg https://dl.dropboxusercontent.com/u/8384811/Misc/network.jpg

What additional information you need to solve this issue?

I made tcpdump during unit test running for lo interface and it take 1.6GB. You may get it on the next link (about 220MB zip) https://dl.dropboxusercontent.com/u/8384811/Misc/dump.zip As you may see this is all gradle communication. So this is planned by design. Could you tell me is this the root of not enough memory issue and is this a way to switch off this local network communication?

Hi Alexandre,

Thanks for the report. We’ll dig in to this in the new year.

Is there any chance you could create a sample project that exhibits this problem for you and give us access to it?

In case it helps - I’m seeing the same issue as Alexandre in a different scenario. I’m using gradlefx, which is calling an ant task to compile flex unit tests (FlexUnitTask), which blows up the JVM. My build was previously working, and I can’t figure out what changed to cause the problem. I can only assume I’ve crossed an invisible bound of some sort.

The errors alternate between Java heap space, and GC Overhead Limit Exceded, depending on GRADLE_OPTS used, and the amount of free memory on my pc.

Runing with: gradle test --debug -DGRADLE_OPTS=-Xmx4076m-XX:-UseGCOverheadLimit

Causes my 8 CPU dev machine to reach 90% CPU usage, before failing with a Java heap space error.

Previously this was working fine without passing anything in GRADLE_OPTS.