Gradle Daemon

Daemon Process definition:

A daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user.

— – Wikipedia

A daemon is a computer program that runs as a background process and is not under the direct control of an interacting user. If you are familiar with Java threads, you must know that Java threads also have a daomon parameter. You can set this thread as a daemon thread, which runs in the background and does not directly handle user interaction logic. So much for Daemon concepts.

It is well known that Gradle runs on a Java virtual machine (JVM) and the support libraries it requires require some initialization time, so Gradle initialization takes some time. The solution to this problem is Gradle Daemon: a process that runs in the background for a long time and avoids frequent initialization. Gradle caches Project data in memory to speed up builds. There are no side effects to using Gradle Daemon, it is very simple to use, it costs nothing, Gradle Daomen is completely transparent to our users.

Why is Gradle Daemon important to improve the performance of builds

Daemons are long-life processes that not only avoid the resource consumption of initialization each time a build is started, but also cache projects, tasks, outputs, files and other data in memory. The reason is simple: speed up builds by reusing calculations from previous builds. And the benefits are significant: we concluded that build times on subsequent builds can typically be reduced by 15-75%. We recommend using — Profile to analyze your build to see how much influence the Gradle daemon has on your build. Gradle Daemon is enabled by default after Gradle3.0

View the status of the daemon process

Use –status to check the status of the daemon

./gradlew --status
gradle --status
Copy the code

Here’s an example:

    PID VERSION                 STATUS
  28411 3.0                     IDLE
  34247 3.0                     BUSY
Copy the code

Note that only daemons of the same version as the Gradle being called are displayed, and no other versions are shown. In the future Gradle may touch on this limitation and implement all versions of running daemons.

Disable Gradle Daemon

The Gradle daemon is enabled by default and we recommend that it be enabled at all times. You can disable Gradle daemons with the command line option — no-daemon, or add org. Gradle. Daemon =false is configured in gradle.properties. In order to satisfy the JVM options required for a build, Gradle typically generates a separate process for the build, even if the daemon option is disabled. If the daemon option is disabled, Gradle typically creates a new separate process at each build in order to satisfy the JVM options required for the build.

Note: Regardless of Gradle version, Gradle builds much faster when daemons are enabled

Since Gradle 3.0, daemons are enabled by default. Daemons are recommended for both development machines and servers. However, we can turn off the daemons option if we feel that enabling the daemons for CI processes on the server will cause instability to the build. Because every build creates a new process,

Stop running daemons

As mentioned above, the daemon is a background process. However, you don’t have to worry about the memory usage of building Gradle processes on your machine. Each daemon monitors its own memory usage and compares it to the total system memory, and when the available system memory is low, the daemon will stop itself when idle. If you want to explicitly stop running the daemon, just use the gradle — stop command.

gradle --stop
Copy the code

This terminates all daemons started with the same Gradle version. If you have a Java Development Kit (JDK) installed, you can easily verify that the daemon has been stopped by running the JPS command.

FAQ

How do I disable the Gradle daemon?

There are two recommended ways to disable daemons:

  • By environment variable: Add flags-Dorg.gradle.daemon=falsetoGRADLE_OPTSThe environment variable
  • throughbuild.propertiesFile: Addorg.gradledaemon=false 到The « GRADLE_USER_HOME » / gradle. The propertiesIn the file

Both methods have the same effect. Which one to use depends on personal preference. However, most of us developers choose the second option by adding options to the build.properties file

windows:

(if not exist "%USERPROFILE%/.gradle" mkdir "%USERPROFILE%/.gradle") && (echo. >> "%USERPROFILE%/.gradle/gradle.properties" && echo org.gradle.daemon=false >> "%USERPROFILE%/.gradle/gradle.properties")
Copy the code

UNIX-like:

mkdir -p ~/.gradle && echo "org.gradle.daemon=false" >> ~/.gradle/gradle.properties
Copy the code

Once daemons are disabled in the build environment, Gradle daemons will not be started unless explicitly requested with the — Daemon option. The — daemon and — no-daemon command-line options enable or disable daemons for single build calls when using the Gradle command line. These command line options have the highest priority when considering building an environment. In general, it is more convenient to enable daemons for your environment so that all builds use daemons without needing to remember to provide the — Daemon option.

Why does my computer have multiple daemons?

Gradle creates a new daemon instead of using an already running daemon a few basic rules are that if there are no free or compatible daemons, Gradle will start a new daemon. Gradle kills any daemons that have been idle for more than 3 hours, so you don’t have to worry about cleaning them up manually.

  • Idle: A daemon that is not currently performing builds or other useful work.
  • Compatible: The Compatible daemon process is a daemon that meets the requirements of the requested build environment. The Java runtime used to perform the build is an example aspect of the build environment. Another example is the set of JVM system properties needed to build the runtime.

The daemons may not satisfy some of the options or configurations of the requested build environment. If the daemon runs with the Java 8 runtime, but the requested environment calls Java 10, the daemon is incompatible and another daemon must be started. Also, some properties of the Java runtime cannot be changed once the JVM is started. For example, you cannot change the memory allocation of a running JVM (such as -XMX1024m), default text encoding, default locale Settings, and so on.

The following JVM system properties are virtually immutable. If any of these properties is required by the requested build environment, and the value of these properties is different from the value that the daemon’s JVM assigns to the property, the daemon is incompatible.

  • file.encoding

  • user.language

  • user.country

  • user.variant

  • java.io.tmpdir

  • javax.net.ssl.keyStore

  • javax.net.ssl.keyStorePassword

  • javax.net.ssl.keyStoreType

  • javax.net.ssl.trustStore

  • javax.net.ssl.trustStorePassword

  • javax.net.ssl.trustStoreType

  • com.sun.management.jmxremote

The following JVM properties controlled by startup parameters are also virtually immutable. In order for the daemon to be compatible, the corresponding properties of the requested build environment and the daemon’s environment must match exactly.

  • The maximum heap size (i.e. the -Xmx JVM argument)

  • The minimum heap size (i.e. the -Xms JVM argument)

  • The boot classpath (i.e. the -Xbootclasspath argument)

  • Assertion Status (i.e. The -EA argument)

Working with multiple Gradle projects simultaneously while using different Gradle versions is also a common reason to have multiple running daemons.

How much memory does the daemon use, and can I give it more?

If the requested build environment does not specify a maximum heap size, the daemon will use up to 512MB of heap. It will use the JVM’s default minimum heap size. 512MB is sufficient for most builds. Large builds with hundreds of sub-projects, lots of configuration, and source code may require more memory, or perform better.

To increase the amount of memory available to daemons, you can specify appropriate flag bits or options for your build environment

How do I stop a daemon?

The daemon automatically terminates in three hours or less. If you want to stop a daemon before this, you can stop the daemon from your operating system or by running gradle –stop. — The stop switch causes Gradle to request that all running daemons (the same Gradle version that ran the command) terminate themselves.

What can go wrong with the daemon?

The Gradle team has put a lot of engineering work into developing daemons to make them robust and transparent during daily development. However, daemons can occasionally become corrupted or have problems. Gradle builds can execute arbitrary code with multiple sources. Although Gradle itself is designed for daemons and has been extensively tested, user build scripts and third-party plug-ins can break daemons through defects such as memory leaks or global state corruption.

Running a build that does not release resources properly can also destabilize the daemons (and the build environment in general). This is a particularly acute problem when using Microsoft Windows, which is less tolerant of programs failing to close files after reading or writing them.

Gradle proactively monitors heap usage and tries to detect when leaks start running out of available heap space in the daemon. When it detects a problem, the Gradle daemon completes the currently running build and actively restarts the daemon on the next build. This monitoring is enabled by default, but can be set by org. Gradle. Daemon. Performance. The enable – monitoring to false to disable.

If you suspect that the daemon is becoming unstable, you can simply kill it. Recall that you can specify the — no-daemon switch for your build to prevent the use of daemons. This is useful for diagnosing whether the daemon is the cause of the problem.

Why do daemons build faster?

The Gradle daemon is a long-running process. During the build, it waits idly for the next build. This has the obvious advantage that Gradle only needs to be loaded into memory once for multiple builds, rather than once for each build. This in itself is a significant performance optimization, but it goes further than that.

An important part of modern JVM performance is runtime code optimization. For example, HotSpot (the JVM implementation provided by Oracle and used as the basis for OpenJDK) optimizes code while it is running. Optimization is incremental, not instantaneous. That is, the code is gradually optimized during execution, which means that subsequent builds are made faster by this optimization process. HotSpot experiments have shown that it takes between five and 10 builds to achieve stable optimizations. For a daemon, the difference in build time between the first build and the 10th build is significant.

This daemon also allows for more efficient memory caching between builds. For example, classes required for a build (plug-ins, build scripts, for example) can be kept in memory between builds. Similarly, Gradle can maintain an in-memory cache of build data, such as hashes of task inputs and outputs, for incremental builds.

To detect changes to the file system and calculate what needs to be rebuilt, Gradle collects a lot of information about the state of the file system at each build. When monitoring a file system is enabled, the daemon can reuse the information gathered from the last build. This can save a lot of time for incremental builds because the number of file system changes between builds is usually low.