Closed SheliakLyr closed 2 years ago
JvmLocalCache
is a workaround we added in 6.0
to make the configuration cache work. We described the reasoning around this in #987.
There's two main workarounds:
lineEndings 'UNIX'
(this will put less data into the cache than the default value GIT_ATTRIBUTES
)5.17.1
- you'll lose support for configuration cache, but you'll get better memory consumption (with this downgrade, the line endings won't matter anymore)I'd be curious to see how much either of the downgrades above help for your case.
Thank you for the tips @nedtwigg. I did some tests but right now I do not have any conclusive results, I stopped being able to OOM the build. We might have introduced some other change in the meantime, or maybe I need to run the build multiple times with some specific changes... can't say.
Right now, JvmLocalCache takes 400MB of memory after running spotlessApply. Changing 'lineEndings' does not seem to do much - most of the memory is kept in ":steps" attributes.
Downgrading spotless of course removes JvmLocalCache, so comparisions are more difficult, but the memory of the entire process stays roughly the same.
For now, I will set lineEndings to UNIX (I had to do it for other reasons as well) and see how the build behaves. I guess this issue can be closed for now, I can open a new one if I find a real cause of the problem.
Downgrading spotless... the memory of the entire process stays roughly the same
That's good news! When we were building JvmLocalCache
, we knew there was a risk of being too memory hungry, and we did do some work to slim it down.
Thanks for opening this issue, and happy to revisit if anything new comes to light.
I have a very large multi-module project build by gradle. Recently, I have added a spotless plugin to some of the modules (let's say 20 out of a few hundreds).
With spotless plugin applied, the build uses much more memory. My current memory setting is
-Xmx3700m
for gradle daemon and the build often fails due to OOM exception. Checking the memory snapshot, I can see that the biggest object is thecom.diffplug.gradle.spotless.JvmLocalCache
. It retains (keeps in memory) almost 1.5GB of data.I cannot provide you with a snapshot, but I have discovered, that this cache holds some questionable objects, like DefaultResolverStatus'es. I think, that scalafmtStep might be responsible for inserting those large objects into the cache:
Gradle version: 7.4.0 Gradle spotless plugin: 6.3.0 Operating system: Arch, Ubuntu