Opening a Gradle build in IntelliJ IDEA spawns a Gradle daemon per previously open .gradle.kts script

[eskatos]

Current Behavior

When opening a project that was previously closed with Gradle Kotlin DSL scripts open, IntelliJ IDEA reopens those scripts. This spawns a Gradle daemon per open Gradle Kotlin DSL script. Having tens of scripts open does sound reasonable.

On the other hand, when starting with no script opened and opening a bunch one after the other, a single Gradle daemon is spawn and reused properly.

What I think happens is that the dependencies of open scripts are all requested concurrently when a project is open. The Gradle daemon does not support concurrent Tooling API requests, so a new daemon is spawn to fulfill each request.

The daemons do expire quickly but until they are all done it puts a lot of stress on the system with processes eating memory, re-doing the same things, and, fighting for shared resources.

Steps to Reproduce (for bugs)

• Import a Gradle build making use of the Kotlin DSL in IntelliJ IDEA
• Open a bunch of .gradle.kts files
• Close the project
• Kill all Gradle daemons
• Open the project
• Observe one Gradle daemon being spawn per previously open script

Your Environment

I can reproduce this on various builds using Kotlin IntelliJ Plugin 1.2.50 or 1.2.60-eap-7.

Expected Behavior

Not a fork bomb.
A single Gradle daemon should be enough.

[eskatos]

Logging static and instance invocation counters from the resolver it seems the IntelliJ Kotlin Plugin reuses the resolver instances per script template, instances are in isolated classloaders though. IOW, one classloader and resolver instance for all *.init.gradle.kts scripts, another one for all *.settings.gradle.kts scripts and another one for all *.gradle.kts.

The best we could do to mitigate the issue is to add a queue to our resolver. There still would be room for 3 concurrent TAPI requests across script templates. Not perfect, but not a fork bomb anymore.

[bamboo]

Fixed in 4f0c82f.