From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Gradle Version
```------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------

Build time:   2022-03-31 15:25:29 UTC
Revision:     540473b8118064efcc264694cbcaa4b677f61041

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          11.0.14.1 (SAP SE 11.0.14.1+1-LTS-sapmachine)
OS:           Mac OS X 12.4 x86_64```

`gradle.properties`
```org.gradle.vfs.watch=false
# org.gradle.jvmargs=-Xmx2G "-XX:MaxMetaspaceSize=256m" -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8```
even bumping max heap to 2Gi didn’t’ help

what is “a lot of files”?  Perhaps there’s a symlink being following creating a cycle?

a lot of files = ~300k
yes, symlinks are involved but as far as I can tell for now, no cycles

if I run exactly the same build with 6.9.2, it works

interesting.  how is the delete being performed?  are the files an input to a task?

I had some performance issues with the delete in the past and wrote a custom task that uses java.nio instead of Gradle built-ins

interesting.  if you comment out the actual deleting - does it still run out of memory?

changed the delete task implemention to noop -&gt; no crash

hmmm.  perhaps there is a leak in som e of the NIO stuff, it can be finicky.  Some of those streams require being closed.

after looking at the task defintion again:
the base folder (starting point of the walk) is defined as @InputDirectory DirectoryProperty baseFolder;

How much Gradle magic does this annotation conjure up? :smile:

Much magic there.  It will fingerprint the contents of the directory, looking for changes.  If this is a cleanup task - where you are explicitly running it, for example - and optimizations such as skipping unnecessary tasks aren’t important - you can change this to @Input (or @Internal) to avoid the per-file-fingerprinting.

yep, that’s it.
Changed to `@Input` and all is well again

if you're deleting it, presumably you want <https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/Destroys.html|@Destroys>?

every day you learn something new :slightly_smiling_face: