TY for taking a stab at this. I'll start working through it.

For starters:

If a longer path with more exclusions is traversed first you might get a longer path than if a shorter path is traversed first because the if (updated) check will prevent the dependencies being traversed if a shorter or equal path already exists.

IIUCupdated is true even if only the hop counts changed:

But indeed, this means we might perform a traversal merely for the purpose of tracking the excluded hop count (which we will not need inFewestModules).

Yep, you are right. I was incorrectly thinking that it was possible to get it to not propagate the new excluded hop count to a previously visited path but that is impossible. It does mean that it has to traverse all paths to find the maximum but we can simply do that as a second pass without worrying about the actual path and blowing up the heap.

Some rough benchmarks with 6G of memory runningclient/clean;client/fullLinkJS with-Dsbt.task.timings=true:

[info]   client / Compile / fullLinkJS                                        :  4625 ms

• This is after 5 runs. It starts at ~13s and gets faster every run.

I'm fairly confident that it is doing the right thing.

Here is what our modules look like on our master branch with 1.6.0 before I ran into this bug:

Here is after my big refactor which started triggering the OOMes with the changes in this PR:

Dunno what's up with those two targets that fail to find the logs. Is that flaky?

Logs are automatically deleted after a while (one week I think?) because they're really huge and fill up our hard disks pretty quickly. The pass/fail information is kept and is still relevant. I'll rerun the tests so you get the logs back. If you want to look at them later, make a copy. ;)

Ah Scalastyle. Pretty cryptic error messageexpected start of definition, but was Token(VAL,val,1619,val). I think it doesn't like 2locally blocks withvals with the same name 😞 .

Oh nope there were trailing commas. Lovely...