mvnd - the Maven Daemon

Let’s have a look at the boot costs first. For Maven, they can be quantified through a simple experiment. In Maven source code, we find the location where Maven starts its own build duration measurement. That’s the baseline for the famous BUILD SUCCESS/Total time: message at the end of every Maven build. We can say that this is the point where Maven starts doing something useful. Everything that happens before can be considered a boot up cost.

So we place the following statement around there

and invoke something as simple as mvn clean prepending it with a shell time output in milliseconds, like this:

It outputs two numbers. On my Lenovo P1 Gen 3 laptop those were 1634117024986 and 1634117025765 respectively. Subtracting them gave the result of 779 milliseconds. That’s the time needed to boot the JVM and load all classes necessary for Maven to start doing something useful. Three quarters of a second. That’s quite a lot, isn’t it?

Java source files are compiled by javac to bytecode at build time. However that’s not the kind of code runnable on any physical processor. The bytecode is yet to be translated to instructions comprehensible to some given processor. This initially happens "on the fly", as the JVM is executing the methods of the application. Every method is first executed in this basic interpreter mode. Only if some method is executed often enough (becomes warm), the JVM decides to compile it using the quick compiler. Once the given method gets hot, i.e. it is executed very often, the JVM compiles it using the optimizing compiler. Apparently, the JIT compilation requires some computing resources itself. Hence to make the application faster, it slows it down first by spending CPU time on the compilation and optimizations.

What is the impact of this on Java build tools?

It is quite substantial, because builds are rather short living processes. The boot costs of 0.78 seconds may well translate to a substantial portion of the overall build duration.

As for the effect of JIT compilation, the code of a short living build is either running in the slow interpreter mode or if JIT compilation kicks in at all, its overhead can hardly pay back before the process exits.

Having a background process (daemon) that survives the individual builds is a very straightforward solution to both of these problems. This background process then hosts the actual build and the command line utility is just a thin client for it.

While Gradle has it since long, it is rather new in Maven.

Let’s try it out.

In case of Maven, the client is a brand new program called mvnd (or mvnd.exe on Windows) that has little in common with the traditional mvn script. Although it is written in Java, it is compiled to native executable using GraalVM. To be precise, this is the case only for platforms supported by GraalVM. There is a shell script (mvnd.sh) wrapping mvnd-client.jar for the platforms unsupported by GraalVM.

Why did we bother to port the client to GraalVM? Except that it was fun, it has also brought some performance benefits. GraalVM native executables are known for extremely fast boot up times and low memory footprint. That’s exactly what we needed. Besides, by having a single client executable, we eliminated another slowing down process in the execution chain: the shell script.

So we have the mvnd command line client that starts quickly. What does it actually do?

First, it looks whether some Daemon process is running and whether it is free for accepting build requests. It does so by reading the Daemon registry stored in ~/.m2/mvnd/registry/<version>/registry.bin. If there is no free Daemon, a new one is launched by the client. Then the client connects to the Daemon through a network socket and passes the command line parameters along with the environment of the current shell to the Daemon.

The Daemon accepts the request and starts executing it. As the build proceeds, it sends notifications about the progress back to the client. The client visualizes the state of the build in its text-based user interface.

The Daemon process is a traditional JVM. It embeds a specific Maven version. The Maven version cannot be changed in any other way than by switching to another mvnd version.

The Daemon reads pom.xml files, loads plugins, downloads dependencies and all the other things that Maven usually does. The main difference against stock Maven is that the Daemon does not exit upon build termination. It stays alive listening on the network socket and waiting for new requests from clients.

Another difference against standard Maven is that Maven Daemon keeps a cache of classloaders holding references to Maven plugin classes. Hence if you keep building the same project with the same plugins during the day, chances are high that you’ll eventually run the optimized code produced by the second level JIT compiler.

Of course, the Daemon terminates at some point. The exact point in time depends on whether the given Daemon is the only one running. In such a case, it exist after 3 hours of being idle. This value is configurable - see the Configuration section below.

If there are other Daemons running that were idle for longer time than the current Daemon, then the current Daemon exists much faster - the default is 10 seconds and it is also configurable.

The state of the running Daemons can be inspected using mvnd --status command. Here is an example output:

Note that the RSS column shows the amount of memory occupied by the given Daemon process.

All running Daemons can be stopped by invoking

Unlike standard Maven, mvnd builds multimodule projects in parallel.

The default number of build threads is given by the expression Runtime.getRuntime().availableProcessors() - 1.

Another condition is that the dependency relationships between the modules in the current source tree must actually allow a parallel build.

For example, if there are three modules A, B and C to be built and the dependencies look like the following

then the module A is built first. After that, the modules B and C can be built in parallel.

This kind of parallel execution brings substantial speedups in "wide" module graphs where there are many siblings having a few common dependencies.

We have demonstrated the mvnd speed gains for large multimodule builds. But some folks do not build large multimodule projects at all. There are also small and single module projects. Or one can build a single module within a hierarchy. Would there be any speed benefits there?

Let’s have a look at an example. Gizmo is a single module project having 50 main Java classes and 40 test classes.

There is no gain from parallel execution here because we build just a single module. All we can see are the gains from reusing the warmed-up Daemon JVM.

We see that the first mvnd run is slower than the mvn baseline. This can be explained through the overhead caused by starting the Daemon and connecting to it through a network socket.

But already the second mvnd build is 4.66 faster than the mvn baseline. 0.61 seconds vs. 2.86 seconds is a difference clearly perceivable by a human. The third one is even faster. 0.52 seconds is pretty snappy for this kind of build.

When describing the way how client looks for an idle Daemon, we omitted an important detail: the discriminating start parameters. Those define the essential characteristics of the Daemon, such as the Java installation path, maximum heap size, etc. which make it exclusive for some given build tasks.

For example, if I set JAVA_HOME to my Java 11 installation directory for the current shell, I do not want mvnd to pick a Daemon running on any other Java, even if such Daemon is idle. I rather want mvnd to always pick a Daemon running on this exact Java even for the price of starting a new Daemon.

Here are some discriminating start parameters along with a short description what they do:

-Djava.home=<path> - Java home for starting the daemon. Env. variable: JAVA_HOME

-Dmvnd.idleTimeout=<duration> - a time period after which an unused Daemon will terminate by itself. Default: 3 hours

-Dmvnd.duplicateDaemonGracePeriod=<duration> - period after which idle duplicate Daemons will be shut down. Duplicate Daemons are daemons with the same set of discriminating start parameters. Default: 10 seconds

-Dmvnd.maxHeapSize=<memory_size> - the -Xmx value to pass to the Daemon. This option takes precedence over options specified in -Dmvnd.jvmArgs.

Let’s assume that the modules in your project depend on each other as shown in the graph below:

As long as you use the serial builder, the modules are always built in the same order and each module is fully built before any subsequent module built is started. Hence the order is always A, B, C.

It is very easy to start relying on this constant and strictly serial ordering. For example the build of module C could be reading a file in B's target folder. Or C's tests could dynamically read an artifact produced by B from the local Maven repository.

All these assumptions won’t hold anymore once you switch to a parallel builder. B can be built in parallel with C. As a consequence of that strange exceptions may occur. The build of C may throw a FileNotFoundException if the desired file is not yet there in B’s `target directory. Or you may see a ClassNotFoundException if the build of C opens an unfinished jar that is just being produced by B.

A simple and straightforward remedy would be to force serial build by using -1/--serial parameter.

Another option is to make the dependency explicit. If you do not want to propagate the dependency to runtime, you can use the test scope and exclude all transitives as follows:

This won’t add any real dependency to C but it will guarantee that B is fully built before C.

Plugins may do all kinds of bad things that need to be avoided in parallelized environments. Maintaining mutable global state (via static field or system property) is a typical example that will inevitably lead to issues once the shared resource is accessed concurrently.

In such situations, the -1/--serial command line parameter may help again. Reporting the issue to the plugin maintainers might however bring better results in the long term.