I've checked the PR changes mentioned in https://github.com/apache/maven/issues/12667 and noticed that for maven-resolver and maven these are targeted to master branches. Currently, the maven-resolver master is 2.0.22-SNAPSHOT, for maven it's 4.1.0-SNAPSHOT (not 4.0.0-SNAPSHOT). The master branch of maven cannot be easily switched from 2.0.21 to 2.0.22-SNAPSHOT as it has breaking changes, so I had to put these changes on top of 2.0.21. Same for the maven-4.0.x branch, these cannot be cherry-picked as there are git conflicts. *I've expected that the provided fixes are targeted to 4.0.0, and not postponed to 4.1.0 release.* So, I've assembled a mix that was compilable and started the build locally.
The `/path/to/mvn41/bin/mvn validate` (not even package) failed with OOM: ``` [ERROR] Java heap space -> [Help 1] [ERROR] java.lang.OutOfMemoryError: Java heap space [ERROR] Java heap space -> [Help 1] ``` The heap dump has these top entries, which we discussed recently [image: Screenshot 2026-08-05 at 14.23.47.png] To avoid ambiguity, it would be nice to have a "reference" branch aggregating all these changes (for both maven-resolver and maven, install and deploy plugins are not critical). Maybe I'm missing something. On Mon, Aug 3, 2026 at 2:01 PM Guillaume Nodet <[email protected]> wrote: > Hi all, > > I've been profiling Maven 4 RC6 on a large reactor (4,383 modules, > diamond-graph, generated with maven-multiproject-generator) as several > performance regressions were found during in the vote thread compared to > Maven 3. A clean install -DskipTests that takes ~1:15 on Maven 3.9.16 was > taking ~2:45 on Maven 4 RC6. > > After a series of JFR-guided optimizations across 4 repositories, Maven 4 > now completes the same build in ~1:18 — at parity with Maven 3. > > Benchmark (Apple M4 Pro, JDK 21): > > | Configuration | Wall time | > |----------------------------|----------------| > | Maven 3.9.16 | 1:14 – 1:18 | > | Maven 4 RC6 (unpatched) | 2:45 | > | + all optimizations | 1:18 | > > The full analysis (JFR hotspots, root causes, complexity reductions) and > all 8 PRs are tracked in: > https://github.com/apache/maven/issues/12667 > > The main wins are: > 1. Switching the default conflict resolver from classic (O(N²)) to path > (O(N)) — single biggest win, 2:45 → 1:45 > 2. TransitiveDependencyManager optimizations — instance reuse, cons-list > parent pointer, varargs elimination > 3. Reactor sort O(N² log N) → O(N log N), model building pipeline > allocation reduction > 4. Install/Deploy plugin O(N²) reactor scans → O(N) with caching > > All PRs are green and ready for review. > > Regards, > Guillaume >
