RFR: 8369039: JDK-8348611 caused regression in Javac-Hot-Generate

[Claes Redestad]

On Mon, 6 Oct 2025 16:03:11 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The refactoring in [JDK-8348611](https://bugs.openjdk.org/browse/JDK-8348611) caused a regression in compiler performance. In the the refactoring there were a couple of simple optimizations that were missed. When put in place, these seem to (mostly) address the performance issue.

I haven't been able to run this through our wider performance lab yet due to some issues on my end, but in local testing I'm not seeing that much of an improvement in my diagnostic tests (the tests are a bit noisy).

Running the benchmark with `-prof gc` shows that the regression correlates with a 17% increase in allocation pressure. This PR only reduces allocation pressure by about from the elevated state 1%:


26-b11: 15.06 GB/op
26-b12: 17.61 GB/op
pr/27651: 17.46 GB/op


Looking at hot methods I see one of the lambdas in `LintMapper$FileInfo` (allocated in the constructor) being relatively hot and I think the abundant use of capturing lambdas in JDK-8348611 might be cause for some unexpected allocation overheads. 

For example desugaring the stream in the `FileInfo` constructor (which was the only thing I saw on `jfr view hot-methods` that seemed related to JDK-8348611):

            tree.defs.stream()
              .filter(this::isTopLevelDecl)
              .map(decl -> new Span(decl, tree.endPositions)) 
              .forEach(unmappedDecls::add);

to this:

            for (JCTree decl : tree.defs) {
                if (isTopLevelDecl(decl)) {
                    unmappedDecls.add(new Span(decl, tree.endPositions));
                }
            }

.. reduces allocation to 16.68GB/op (reducing the relative increase in allocations by about 1/3 compared to pr/27651)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27651#issuecomment-3377077619