# How Gradle Works Part 2 - Inside The Daemon

DevFeed: [How Gradle Works Part 2 - Inside The Daemon](<https://devfeed.tech/articles/how-gradle-works-part-2-inside-the-daemon-24643.md>)

Original publisher: [Read original article](<https://blog.gradle.org/how-gradle-works-2>)

Author: Bo Zhang

Published: 2023-01-21T07:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [build times](<https://devfeed.tech/topics/build-times.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [Java](<https://devfeed.tech/topics/java.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>), [client](<https://devfeed.tech/topics/client.md>), [Logging](<https://devfeed.tech/topics/logging.md>)

Tags: [build-times](<https://devfeed.tech/tags/build-times.md>), [caching](<https://devfeed.tech/tags/caching.md>), [command-line](<https://devfeed.tech/tags/command-line.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [groovy](<https://devfeed.tech/tags/groovy.md>), [java](<https://devfeed.tech/tags/java.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>), [logging](<https://devfeed.tech/tags/logging.md>), [optimization](<https://devfeed.tech/tags/optimization.md>), [process](<https://devfeed.tech/tags/process.md>)

## AI overview

This article explains how the Gradle Daemon works inside the JVM. It covers daemon reuse, caching, JVM startup avoidance, runtime optimization, file-system monitoring, client communication, and the initialization and configuration phases of a Gradle build.

## Source excerpt

Previously on How Gradle Works: How Gradle Part 1 - Startup This is the second blog of the series How Gradle Works. In this blog we'll explain what happens inside the Gradle Daemon JVM. Why We Need Gradle Daemon? In the last blog, we mentioned that Gradle starts a Gradle Daemon JVM ("the daemon") to run the build. The userguide explains why we need the daemon. The Daemon is a long-lived background process that reduces the time it takes to run a build. The Daemon reduces build times by: caching project information across builds running in the background so every Gradle build doesn't have to wait for JVM startup benefiting from continuous runtime optimization in the JVM watching the file system to calculate exactly what needs to be rebuilt before you run a build The Gradle daemon was introduced in Gradle 3.0 and became mature over the years. It's enabled by default, and we don't recommend disabling it under any circumstances. What Happens in the Daemon? After Gradle Client JVM ("the client") connects to a compatible idle daemon, it sends the necessary build information (command line arguments, project directory, env variables, etc.) to the daemon. The daemon then starts running the build and sends build output (logging, stdout/stderr, etc.) back to the client. The communication happens via a local socket connection. But what exactly happens inside the daemon? The userguide explains that there are three phases in a Gradle build: Initialization, Configuration, and Execution. Initialization Phase: Creation of Build Objects Now that the daemon knows everything about the build, it starts creating the internal representations for the build. Because Gradle runs on the JVM, these representations are Java objects. For example, the whole Gradle build invocation is represented by a Gradle instance. The configuration required to configure the project hierarchy is represented by a Settings instance. There is a Project instance corresponding to each project we're trying to build. G