3

When I start Eclipse with the Gradle plugin on, sometimes literally hundreds of Java processes will suddenly spawn. They look like this:

26000 pts/24 Sl 0:01 /usr/lib/jvm/default-java//bin/java -Dfile.encoding=utf-8 -Xmx512m -XX:MaxPermSize=128m -XX:+UseG1GC -Dorg.gradle.appname=gradlew -classpath /[...]/gradle/wrapper/gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain [project name]:eclipseExternalBuild --configure-on-demand -Dorg.gradle.parallel=false

26230 pts/24 Sl 0:04 /usr/lib/jvm/jdk1.7.0_51/bin/java -XX:MaxPermSize=2048m -Xmx4096m -Dfile.encoding=UTF-8 -cp [...]/.gradle/wrapper/dists/gradle-1.8-all/2kopnp0i5dq014k75fp36m3vd5/gradle-1.8/lib/gradle-launcher-1.8.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 1.8 [...]/.gradle/daemon 10800000 4d4119b1-c332-4714-b0cd-1e80bc6dd78f -XX:MaxPermSize=2048m -Xmx4096m -Dfile.encoding=UTF-8

The first kind of process looks like Eclipse is building things; there seems to be at least one (sometimes up to 6!!) process for each project within my workspace. They go away after a few minutes, which is reasonable.

What is annoying is that I have no idea what all the GradleDaemons are doing.

Gradle dependency management is enabled within Eclipse. I'm using Eclipse 4.4 and Gradle 1.8 on Ubuntu 14.04.

How do I fix this? I'm basically calling killall -9 java every few hours when my computer starts being unresponsive.

Community
  • 1
  • 1
jiangty
  • 311
  • 2
  • 9

1 Answers1

1

I don't know if I can fix the problem for you but at least I can give you guidance about some things here. The first set of daemon processes after Eclipse launch is created to obtain model of a project to populate classpath of your projects. They are likely to have some short timeout if they die quickly.

Process 26000 looks more like a command line invocation to me than a process initiated by Eclipse plugin. Two consecutive slashes in /usr/lib/jvm/default-java//bin/java seems weird to me. Do you have JAVA_HOME set with a trailing slash?

If you have so many processes running simultaneously then each build request probably starts a new one with 3 hours timeout (10800000 millis parameter in the output). You can customize the timeout using a system property but it would be better to find why Gradle is not reusing an already running daemon process. It should do it assuming that the daemon uses the same JVM, same set of JVM args and possibly some other constraints. There are logs in Gradle user home directory that you can check for any suspicious messages.

Also I'd check some of these process using a thread dump to see if there is deadlock/starvation preventing it from normal processing. I.e. if they do not finish their build execution they won't be reused for next build request and maybe they will not quit after timeout.

Radim
  • 4,721
  • 1
  • 22
  • 25
  • For each Gradle build Eclipse integration creates a new cancellation token sorce and hence a new cancellation token. Would a new cancellation token for gradle build process imply a new gradle daemon process created? – aboyko Oct 23 '14 at 13:53
  • 1
    No, the code that searches for / creates a connection to daemon does not know anything about cancellation tokens. – Radim Oct 23 '14 at 15:46
  • Can you explain what the hash `4d4119b1-c332-4714-b0cd-1e80bc6dd78f` is in `[...]/.gradle/daemon 10800000 4d4119b1-c332-4714-b0cd-1e80bc6dd78f -XX:MaxPermSize=2048m -Xmx4096m -Dfile.encoding=UTF-8`? That would probably be helpful for debugging, since it's the only thing that's different for each of the `GradleDaemon` processes. – jiangty Oct 23 '14 at 21:18