`showMvnDepsTree` hangs

[lefou]

The project has a large number of dependencies, but for some reasons, showMvnDepsTree started to hang without ever returning. I'm pretty sure it used to work before.

stacktrace.txt

> head -n50 stacktrace.txt
2026-02-12 16:04:08
Full thread dump OpenJDK 64-Bit Server VM (21.0.9+10-LTS mixed mode, sharing):

Threads class SMR info:
_java_thread_list=0x00007f8e00001c20, length=41, elements={
0x00007f8ea40302c0, 0x00007f8ea414ac90, 0x00007f8ea414c200, 0x00007f8ea414d980,
0x00007f8ea414efc0, 0x00007f8ea4150560, 0x00007f8ea4152120, 0x00007f8ea41537e0,
0x00007f8ea41602d0, 0x00007f8ea4163520, 0x00007f8ea4876610, 0x00007f8ea49bdc90,
0x00007f8ea49be810, 0x00007f8ea4a43c30, 0x00007f8ea4a4d710, 0x00007f8ea4b02d90,
0x00007f8ea4b05880, 0x00007f8ea526d9d0, 0x00007f8ea526e9c0, 0x00007f8ea5219ff0,
0x00007f8ea52415b0, 0x00007f8ea52426c0, 0x00007f8ea5273a10, 0x00007f8ea5274870,
0x00007f8ea52758f0, 0x00007f8d581af1d0, 0x00007f8d5415ab40, 0x00007f8d3c02a2b0,
0x00007f8d4000a1b0, 0x00007f8d34001c70, 0x00007f8d38001e50, 0x00007f8ea57ba990,
0x00007f8d6c021320, 0x00007f8d5c050460, 0x00007f8ea4fcf230, 0x00007f8d44061810,
0x00007f8d14005f10, 0x00007f8d20001910, 0x00007f8d1c00f750, 0x00007f8d501ca470,
0x00007f8e00000fc0
}

"main" #1 [25984] prio=5 os_prio=0 cpu=14791,10ms elapsed=25,45s tid=0x00007f8ea40302c0 nid=25984 runnable  [0x00007f8eaa08a000]
   java.lang.Thread.State: RUNNABLE
        at scala.collection.IterableOnceOps.exists(IterableOnce.scala:661)
        at scala.collection.IterableOnceOps.exists$(IterableOnce.scala:337)
        at scala.collection.AbstractIterable.exists(Iterable.scala:946)
        at coursier.core.DependencySet.containsModule(DependencySet.scala:134)
        at coursier.graph.DependencyTree$Node$$anonfun$1.applyOrElse(DependencyTree.scala:162)
        at coursier.graph.DependencyTree$Node$$anonfun$1.applyOrElse(DependencyTree.scala:161)
        at scala.collection.immutable.List.collect(List.scala:269)
        at scala.collection.immutable.List.collect(List.scala:254)
        at coursier.graph.DependencyTree$Node.children(DependencyTree.scala:161)
        at coursier.util.Print$.$anonfun$dependencyTree0$11(Print.scala:235)
        at coursier.util.Print$$$Lambda/0x00007f8e24aabdb0.apply(Unknown Source)
        at coursier.util.Tree.$anonfun$customRender$3(Tree.scala:49)
        at coursier.util.Tree.$anonfun$customRender$3$adapted(Tree.scala:43)
        at coursier.util.Tree$$Lambda/0x00007f8e24aad320.apply(Unknown Source)
        at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:633)
        at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:337)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1328)
        at coursier.util.Tree.recursivePrint$1(Tree.scala:43)
        at coursier.util.Tree.$anonfun$customRender$3(Tree.scala:49)
        at coursier.util.Tree.$anonfun$customRender$3$adapted(Tree.scala:43)
        at coursier.util.Tree$$Lambda/0x00007f8e24aad320.apply(Unknown Source)
        at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:633)
        at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:337)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1328)
        at coursier.util.Tree.recursivePrint$1(Tree.scala:43)
        at coursier.util.Tree.$anonfun$customRender$3(Tree.scala:49)
        at coursier.util.Tree.$anonfun$customRender$3$adapted(Tree.scala:43)
        at coursier.util.Tree$$Lambda/0x00007f8e24aad320.apply(Unknown Source)
        at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:633)
        at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:337)

[lihaoyi]

@alexarchambault could you help look at this one? It seems like a non-linear performance issue inside the Coursier tree renderer

[lefou]

This is really a showstopper. I need to fix some real-world classpath issues and can't analyze it properly. The strange thing is, that --whatDependsOn seems to work for some dependencies, that are not highly depended on, but not for others, that are used by more artifacts. I suspect the issue is in the printer/renderer, not the dependency tree itself. Resolution still works, but I can't figure out, why a specific jar is on the classpath.

[lefou]

Maybe unrelated, but I also saw this:

> mill cloud.vaadin.showMvnDepsTree --inverse
558] cloud.vaadin.showMvnDepsTree
Exception in thread "FileToStreamTailerThread" Exception in thread "FileToStreamTailerThread" java.lang.OutOfMemoryError: Java heap space
Exception in thread "chrome-profile-metrics-thread" java.lang.OutOfMemoryError: Java heap space
        at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:301)
        at java.base/java.nio.file.Path.of(Path.java:148)
        at java.base/java.nio.file.Paths.get(Paths.java:69)
        at java.base/jdk.internal.platform.CgroupUtil.lambda$readStringValue$1(CgroupUtil.java:67)
        at java.base/jdk.internal.platform.CgroupUtil$$Lambda/0x00007f0404078f88.run(Unknown Source)
        at java.base/java.security.AccessController.executePrivileged(AccessController.java:809)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
        at java.base/jdk.internal.platform.CgroupUtil.readStringValue(CgroupUtil.java:69)
        at java.base/jdk.internal.platform.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:65)
        at java.base/jdk.internal.platform.cgroupv2.CgroupV2Subsystem.getFromCpuMax(CgroupV2Subsystem.java:140)
java.lang.IllegalStateException: Worker wire broken, worker likely crashed. Connection DaemonRpcClient
        at mill.rpc.MillRpcClient$.mill$rpc$MillRpcClient$$$_$awaitForResponse$1(MillRpcClient.scala:63)
        at mill.rpc.MillRpcClient$$anon$1.apply(MillRpcClient.scala:96)
        at mill.launcher.MillServerLauncher.runRpc(MillServerLauncher.scala:121)
        at mill.launcher.MillServerLauncher.run(MillServerLauncher.scala:52)
        at mill.launcher.MillLauncherMain$.main0(MillLauncherMain.scala:105)
        at mill.launcher.MillLauncherMain$.main(MillLauncherMain.scala:18)
        at mill.launcher.MillLauncherMain.main(MillLauncherMain.scala)

[lolgab]

I'm experiencing hangs in Github Actions when running resolvedMvnDeps.
Example: https://github.com/lolgab/snunit/actions/runs/21903075218/job/63238539156

[lihaoyi]

I saw a hang in resolvedMvnDeps here as well https://github.com/com-lihaoyi/upickle/actions/runs/22011285102/job/63605569178

[alexarchambault]

About showMvnDepsTree, the problem might be specific to Mill. On my machine, it takes half a second for the coursier CLI to print the tree of spark-sql, while it takes more than 2 minutes to do the same from Mill:

$ time ( cs resolve org.apache.spark:spark-sql_2.13:4.1.1 -t | wc -l )
  Result:
   51248
( cs resolve org.apache.spark:spark-sql_2.13:4.1.1 -t | wc -l; )  0,60s user 0,09s system 118% cpu 0,580 total

$ cat build.mill
//| mill-version: 1.1.2

import mill.*
import mill.scalalib.*

object foo extends ScalaModule {
  def scalaVersion = "2.13.18"
  def mvnDeps = Seq(
    mvn"org.apache.spark::spark-sql:4.1.1"
  )
}

$ time ( ./mill __.showMvnDepsTree | wc -l )
./mill __.showMvnDepsTree
16] foo.showMvnDepsTree
16/16, SUCCESS] ./mill __.showMvnDepsTree 129s
   50823
( ./mill __.showMvnDepsTree | wc -l; )  1,73s user 1,66s system 2% cpu 2:10,33 total

[lefou]

I confirm, that cs itself is able to show to full tree. I need to publish my project locally, to be able to inspect it, though.

> mill cloud.vaadin.publishLocal --transitive true
...

> time cs resolve -r ... -t ...cloud.vaadin:...
...
real    0m6,312s
user    0m4,431s
sys     0m0,972s

So, at least we have a workaround. Thanks!

But generating the inverse tree with -T took 5m 47s.

[lefou]

[nguyenyou]

This is likely the same root cause as coursier/coursier#3561 — exponential hashCode() computation on tree Node case classes that carry graph-wide maps.

Both stack traces converge on Tree.customRender → recursivePrint, which uses a Set[Node] for cycle detection. Each ancestors.contains(elem) and ancestors + elem call triggers hashCode() on Node, which recursively hashes large shared data structures (the entire dependency graph). For ~600+ dependencies this becomes O(B^D × N) and never finishes.

The fix proposed in coursier/coursier#3561 is to override hashCode/equals on the Node case classes to only use identity fields (module, version constraint) instead of the shared graph maps.

[lefou]

The same project returns all kind of dependencies trees via iyvDepsTree really fast with Mill 0.12.17, which is on coursier 2.1.25-M13.