Gradle Gradle Daemon

Gradle Daemon

Walk into the daemon

The purpose of the Gradle daemon, sometimes referred to as the build daemon, is to improve the startup and execution time of Gradle.

We've prepared a few useful use cases for daemons. F or some workflows, the user calls Gradle multiple times to perform a small number of relatively fast tasks. For example:

• When test-driven development is used, unit tests are executed multiple times.
• When developing a web application, the application is assembled multiple times.
• When you find out what a build can do, it executes multiple times where the gradle tasks are.

For all of these workflows, it is important to keep the startup cost of calling Gradle as small as possible.

In addition, if you can build the Gradle model relatively quickly, the user interface can provide some interesting functionality. For example, the daemon might be used in the following situations:

• Content help in the IDE
• Build in real-time visualization in the GUI
• The tab key in the CLI is complete

In general, the agile behavior of building tools can always come in use. If you try to use daemons in your local build, it becomes difficult for you to get back to normal Gradle use.

The Tooling API uses daemons throughout the process. F or example, you can't formally use the Tooling API without a daemon. This means that you are already using the Gradle daemon when you are using STS Gradle in Eclipse or Gradle support in Intellij IDEA.

In the future, the daemon will provide more features:

• Agile up-to-date check: Use the local file system to modify notifications (for example, by jdk7 nio.2) to pre-execute up-to-date analysis.
• Faster build: Pre-evaluate the project so that the model is ready when the user next calls Gradle.
• Did we mention faster builds? Daemons can pre-download dependencies or perform snapshot-dependent version checks.
• Use a pool of re-usable threads that you can use for compilation and testing. F or example, both Groovy and Scala's compilers are expensive to start. Building a daemon maintains a downloaded Groovy and/or Scala process.
• Perform certain tasks in advance, such as compilation. Faster feedback.
• Fast, accurate bash tab finish.
• Regular garbage collection for the Gradle cache.

Reuse and fail daemons

The basic idea is that the gradle command will fork a daemon to perform the actual build. S ubsequent calls to the Gradle command reuse the daemon to avoid startup overhead. S ometimes we can't use an existing daemon because it's busy or its java version or jvm parameters are different. F or specific details of a completely new daemon fork, read the topic below. The daemon will automatically fail after 3 hours of idle time.

Here's all about our new daemon fork:

• If the daemon is currently busy running some jobs, a completely new daemon is started.
• For each java home, we'll fork a separate daemon. So even if there are some idle daemons waiting for a build request, and you happen to run the build through a different java HOME, a whole new daemon will be fork.
• If the parameters used to build jvm are different enough, we'll fork a separate daemon. F or example, if some system properties have changed, we will not fork a new daemon. However, if the -Xmx memory settings change, or some basic unchanging system properties change (such as file.encoding), the new daemon will be fork.
• At this point, the daemon is added a specific version number of Gradle. T his means that even if some daemons are idle, a new daemon will start if you are running a different build than Gradle. T his also has the result of a --stop command line instruction: When you run --stop, you can only stop the daemon that started with your Gradle version.

We plan to improve the daemon's management/pooling approach in the future.

Usage and troubleshooting

For information on the use of the command line, take a look at the topic appendix D, the Gradle command line. I f you're tired of using the same command-line options over and over again, you can look at the build environment. This section contains information about how to configure certain behaviors, including turning on daemons by default, in a "persistent" manner.

Here are some aspects of troubleshooting for the Gradle daemon:

• If you have a build problem, try temporarily disabling the daemon (you can do so by using the command-line switch-no-daemon).
• Sometimes, you may want to stop the daemon with the --stop command line option or a more powerful way.
• By default, the Gradle user home directory has a daemon log file.
• You may want to start the daemon in --foreground mode to see how the build is executed.

Configure the daemon

You can configure some daemon settings, such as JVM parameters, memory settings, or java home directories. For more information, see Build An Environment.