Petition Gradle to support JVM-local configuration-cache

[nedtwigg]

Please thumbs-up this issue if you'd like Gradle to build this. TLDR: Unlike remote build cache, configuration cache is never going to be relocatable. Because of that, it might as well be a JVM-local cache (within-daemon), which removes the performance and incidental-complexity penalties of a serialization roundtrip. Spotless #986 hacks a workaround to demonstrate this approach, example API in comment below. Gradle could support this natively so that configuration cache is faster to use and easier to develop plugins against.

EDIT: full no-asterisk support for configuration cache is available in Spotless 7.0.0+

[nedtwigg]

One of Gradle's best features is the build cache (--build-cache or org.gradle.caching=true). It snapshots the input properties of a task and memoizes the outputs. Simple and effective. Best of all, cache artifacts generated on a single CI server can be distributed to all other builds thanks to "remote build cache". However, in order for that relocation to work, you need to annotate every file-based input with one of four PathSensitivity values: NONE, NAME_ONLY, RELATIVE, ABSOLUTE. There's really a fifth value too, which is "unannotated, does not support relocating (neither to other machines nor to other folders on this machine)."

In 6.6, Gradle shipped configuration cache (--configuration-cache or org.gradle.unsafe.configuration-cache=true). It places lots of restrictions on how tasks can operate and coordinate. For Spotless, complying with the simple part of these restrictions required ~150 lines of churn plus another ~200 lines of boilerplate (#982).

But the really tricky restriction, on both incidental complexity and performance, is that all tasks must be able to roundtrip their state losslessly through Java's semi-deprecated serialization system. For Spotless that would require something close to a rewrite, but we were able to hack around it with ~300 lines (#986). The hack is much faster and easier to adopt than Gradle's current approach, so we hope that they will switch.

The advantage of serialization

• It is a "proof-of-isolation" (but not the only one!). If you can put yourself onto disk and take yourself back out, then you have proven that you are isolated from other tasks, which makes it safe to run tasks in parallel by default.

The disadvantages of serialization

• Slow.
• Many useful things cannot be serialized.
• It isn't "real" serialization, there are several caveats to what parts of Java serialization Gradle will let you use.

Sharing configuration cache between machines is going to be error-prone and labor-intensive

There is a feature proposal (gradle/gradle#13510) to share configuration cache information between machines, same idea as remote build cache. Remember that to make that work for the remote build cache, you needed to annotate every input property with a PathSensitivity value. The equivalent for remote configuration cache is for every POJO which contains a system path to be annotated. Given that Gradle isn't using "real" serialization, I suppose they may have a workable plan for this, where you can somehow scope that "any File reference below this is PathSensitivty.NAME_ONLY" or something like that. But it's even harder than that, because build cache didn't need to resynthesize its inputs, it just needed to one-way fingerprint them. What does it mean to take a File implementationDetailFile through a roundtrip of PathSensitivity.NAME_ONLY? This is especially problematic because the easy part of complying with configuration cache is to convert every call to project.projectDir into:

A task input or output property or a script variable to capture the result of using project.projectDir to calculate the actual parameter.

How is a future version of Gradle going to know which need to be rewritten machine to machine, versus which are intended to be left alone? Plus, who cares! Build cache is already effective at offloading work from developer machines to CI machines. The real gold of configuration cache is improving iteration times on a single dev machine (time-to-test), and for that environment you'd happily trade away relocatability to get the fastest possible iteration time. The fastest possible iteration time is not going to have a serialization roundtrip as one of the required steps.

[nedtwigg]

Configuration cache is faster and easier without serialization

Here is an example:

// user-facing
org.gradle.api.LiveCache<T> { get/set }

class MyServerConnection { ... } // implements .equals and .hashCode, but not serializable
class MyTask {
  private final LiveCache<ServerConnection> serverConnection = createLive<>("serverConnection")

  public void setConnection(ServerConnection connection) {
    serverConnection.set(connection);
  }

  @Input
  public ServerConnection getConnection() {
    return serverConnection.get();
  }
  // field/getter/setter could be replaced with @Inject LiveCacheableProperty<ServerConnection> getConnection()

  @TaskAction
  public void performAction(InputChanges inputs) throws Exception {
    serverConnection.get().doStuff()
  }
}

// implementation
data class InternalCacheKey {
  File projectDir
  String taskPath
  String propertyName
}

private static Map<InternalCacheKey, Object> daemonGlobalState = ...

class GradleInternalTaskImplementation implements Task {
  LiveCache<T> createLive(String name) {
    InternalCacheKey internalKey = new InternalCacheKey(projectDir, getPath(), name);
    return new LiveCache<T>() {
      @Override public void set(T value) {
         daemonGlobalState.put(internalKey, value);
       }
      @Override public T get() {
         Object value = daemonGlobalState.get(internalKey);
          if (value == null) {
            throw TriggerConfigurationError(); // we need to rerun configuration to populate our cache
          } else {
            return (T) value;
          }
       }
    }
  }

We implemented the "Gradle side" of this as JvmLocalCache, except that we have no way to do TriggerConfigurationError (but Gradle does!). The whole thing lives in #986 (just ~200 lines).

[eskatos]

Hi Ned,

Thanks for bringing this up.

First, with regards to the configuration-cache serialization: it is not based on Java Serialization - we are not that crazy :) Gradle uses its own serialization mechanism and format for configuration cache entries, it is optimized for i/o, computation and space saving. There is some support for Java Serialization as a fallback. But it is not recommended relying on it and handcrafting serialization. I just tried to make this clearer in the docs in gradle/gradle#19005

We may implement an in-memory cache at some point, for example we’ve talked about pre-creating the task graph at the end of the build in anticipation of the next build. But we think it would still make copies of any mutable structures (for isolation) and would still be backed by a persistent copy (for daemon restarts). Isolating tasks enables running all of them in parallel safely. Using shared mutable state wouldn't work. We’d need some data that shows that the current approach actually has enough of a negative impact on build performance to do something about it (not saying it doesn’t, only that we don’t yet know whether it does or does not).

In terms of relocatabilty, let’s see. We’ve talked about using the remote cache, but we have some work to do before that would be possible. It’s hard to see us doing this without adding some more constraints or asking you to be more explicit about relocation.

[nedtwigg]

If the cache is only shared between sequential builds, then it is not shared mutable state. Just mutable state. And that's a risky thing, but not so risky if you've opted-in to it.

And if Gradle never builds that API, that's okay, because it's very easy to do in userspace.

The only part we can't build in userspace is TriggerConfigurationError. Users will have to do that manually until/unless Gradle builds a way for tasks to say "my cache is cold, I need this build to be a slow reconfigure". I suppose we could workaround that in userspace with something like ./gradlew2 that checks output for TriggerConfigurationError and then does rm -rf .gradle/configurtation-cache and reruns the originally requested task... (#1209)

I think our biggest disagreement is around user story. IMO, the dominant user story is a serial chain of edit -> test -> edit -> test. That story has some built-in constraints, and I would take advantage of those constraints by designing to them. Happy to agree to disagree because we've already got the primitives we need :)

[eskatos]

I meant state shared between tasks.

[nedtwigg]

I might be naive, but that seems like another "design to the wrong point" problem. The worrycase as I understand it is a poorly implemented userland plugin which:

1. defines multiple tasks...
2. which depend on each other enough to share mutable state...
3. but also don't dependOn each other, such that they are eligible to run concurrently...
4. and this mutable state was improperly implemented

I agree it's possible, but it doesn't seem like it's so common that it's worth designing to. Especially when the builds where correctness matters the most are CI builds where configuration-cache doesn't make much sense in the first place.

Let's say that Gradle came with a built-in ./gradlew taskFuzz which

1. performs a no-parallel build and checkpoints the output artifacts
2. looks at the dag to find which tasks could possibly run concurrently with each other
3. bashes on each pair of conceivably-concurrent tasks to see if it can get a bug or at least modify the output
4. outputs a .gradle-parallel-safe file which is a hash of the buildscripts that certifies that this build is safe to run concurrently

With some kind of verification tool, the implementation is no longer responsible for verification, and you open up a lot of design space for the implementation.

The current "verification" tool (roundtrip serialization baked into every execution) is trivially defeated with a static variable containing mutable state. In Spotless, we are doing this on purpose, but it's easy to do this on accident too. A serialization roundtrip won't be able to catch bugs of this type. You could add some classloader magic, but now plugin authors are going to be debugging not only magic serialization, but also magic classloading. You'll also be paying another performance penalty by thrashing the JIT.

With each release of Gradle, I would hope that authoring builds will get easier, and that I will spend less time on the incidental complexity of the jobs I want Gradle to do. My concern with the configuration-cache is that there is a big set of stuff that is fundamentally not serializable, and any build with those things in it makes the entire build a second-class experience. Besides Spotless, I have updated four other public build plugins for configuration-cache, and more private ones:

• Fix the configuration cache support. image-grinder#9
• Add support for the configuration-cache spotless-changelog#27
• Add support for Gradle configuration cache blowdryer#26
• Add support for configuration cache goomph#153

In every case, I am forced to write quite a lot of boilerplate, and formerly straightforward things become quite complicated (e.g. reading project / environment variables).

I would love a feature like "developer-cache", marketed as so:

• Define your build logic in the simplest and most straightforward way that you can, and we'll make sure that the edit -> test -> edit -> test cycle time is as fast as possible.

A "developer-cache" design would be unwilling to incur any runtime costs on verification responsibilities, and it wouldn't spend developer time on relocatability.

[JavierSegoviaCordoba]

Have you thought to implement the "automatic mode" for deleting the configuration cache?

When I tried this feature it was failing mainly in CI which is annoying.

Is it not possible to change the implementation to be really compatible with the Gradle way?