Spotless failed with OutOfMemory on large project (https://github.com/DataDog/dd-trace-java)

[AlexeyKuznetsov-DD]

Follow-up to #2703 — OutOfMemoryError after upgrading to Spotless 8.1.0 and JDK 21

After upgrading Spotless from 6.13.0 to 8.1.0, along with migrating our Gradle build from JDK 8 to JDK 21, we started seeing OutOfMemoryError failures when running:

./gradlew spotlessApply

Observed Behavior

Spotless fails with OutOfMemoryError during formatting. Increasing the max heap from -Xmx4G to -Xmx6G allows the task to complete, but this is unexpectedly high for our project and suggests a memory leak or excessive retention.

Investigation

To better understand the issue, I captured a heap dump and analyzed it using Eclipse Memory Analyzer (MAT). The report highlights unusually high memory usage by the Groovy formatter:

1,682 instances of com.diffplug.spotless.extra.glue.groovy.GrEclipseFormatterStepImpl$GroovyErrorListener,
loaded by com.diffplug.spotless.FeatureClassLoader @ 0x6a46c02f0 occupy 2,079,056,168 (65.92%) bytes.

This strongly suggests that the Groovy formatter step is retaining large amounts of memory, potentially due to the error listener or related parsing structures.

Expected Behavior

Spotless should not require 6GB of heap to format our codebase. Prior versions ran successfully with 4GB. Memory usage should remain stable and not scale disproportionately.

Additional Context

• JDK8 + 6.13.0 — works without issue
• JDK21 + 8.1.0 — triggers OOM unless heap is increased.
• Gradle version is 8.14.3

spotless configuration: https://github.com/DataDog/dd-trace-java/blob/a8d73887e079e0af17e60c037d580c2947d66dbf/build.gradle.kts#L28-L153

I can provide more info if needed.

Request

Could you please check if it is a regression in the Groovy formatter or a known issue with Spotless 8.x?

Thanks!

[bric3]

Note this is happening a repo that has ~600 projects, with various languages, but Groovy is in almost all of them, plus the gradle build scripts.

spotless {
  project.pluginManager.withPlugin('groovy') {
    groovy {
      toggleOffOn()
      if (!groovySkipJavaExclude) {
        excludeJava() // excludes all Java sources within the Groovy source dirs from formatting
        // the Groovy Eclipse formatter extends the Java Eclipse formatter,
        // so it formats Java files by default (unless `excludeJava` is used).
      }
      targetExclude(buildDirectoryFiles)
      greclipse().configFile(configPath + '/enforcement/spotless-groovy.properties')
    }
  }
}

---

I profiled a Gradle daemon running on a large project, and I noticed some significant time spent in NestJars that in particular extract jar archives. Note the dependencies have already been downloaded in previous runs.

Allocations

CPU

Monitor Blocked

In a way looks related to that change ? #1524
Maybe this is something that should be reported as well to https://github.com/equodev/equo-ide ? Maybe not as it might be an issue with spotless alone.

[bric3]

Here's JFR file, with the above flamegraphs.

8.14.3-spotless-8.1.0-spotlessApply.zip

From the stack it looks like that spotless is trying to write something via com.diffplug.spotless.FormatterStepSerializationRoundtrip.HackClone.writeObject which ends up reading NestedJars ?

Opening the profile in IntelliJ is quite useful as well.

We can also see that, this behavior happens for the whole life time of Execution Worker threads.

[bric3]

Using greclipse(), leeds to the creation of an EquoBasedStepBuilder which builds an EquoStep, with a FileSignature.Promised that is re-executed each time the state is requested, e.g. when spotless tries to serialize the configuration.

Unfortunately this lazy computation of the state, has terrible performance impact.

[bric3]

In terms of workaround there's not much but using a different "step". I was able to successfully format groovy code with prettier, with prettier-plugin-groovy plugin (which is using beautify-groovy) but there's not a lot of control, and in the end makes files uglier.

groovy {
  toggleOffOn()
  target("**/*.groovy")
  targetExclude(buildDirectoryFiles)
  prettier(["prettier" : "3.7.4", "prettier-plugin-groovy" : "0.2.1"]).configFile(configPath + '/prettier-groovy.toml')
}

# prettier-groovy.toml
# Reads the .editorconfig file in the project root for base settings

#trailingComma = "es5"
#tabWidth = 2
#semi = false
#singleQuote = true

plugins = [
  "prettier-plugin-groovy", # https://www.npmjs.com/package/prettier-plugin-groovy
]

[[overrides]]
files = ["*.groovy"]
options = { parser = "groovy" }

Another option could to look at npm-groovy-lint that has a format flag-,%2D%2Dformat,-Boolean).

• Add support for npm-groovy-lint #1121