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

[Archie Cobbs]

On Tue, 7 Oct 2025 14:09:49 GMT, Claes Redestad <redestad 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 1% from the regressed state:
> 
> 
> 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)

Hi @cl4es,

> This PR only reduces allocation pressure by about 1% from the regressed state:

Now you're moving the goalposts :) I was looking at the performance benchmark, not allocation pressure...

FWIW this is what I saw on my laptop:

JDK 25

Benchmark                        (stopStage)  Mode  Cnt   Score   Error  Units
SingleJavacBenchmark.compileHot     Generate    ss   10  14.566 ± 0.868   s/op

JDK 26

Benchmark                        (stopStage)  Mode  Cnt   Score   Error  Units
SingleJavacBenchmark.compileHot     Generate    ss   10  16.403 ± 0.214   s/op

JDK 26 + [this patch](https://github.com/openjdk/jdk/compare/master...archiecobbs:d098d010e8c8948bf728dcd3b95eb56f97268871)

Benchmark                        (stopStage)  Mode  Cnt   Score   Error  Units
SingleJavacBenchmark.compileHot     Generate    ss   10  14.807 ± 0.381   s/op

So that patch did seem to help resolve most of the benchmark difference. Are you not seeing the same thing?

But also that patch differs from the one currently committed, in that it includes the `ArrayList` to `LinkedList` changes that were later taken out. Without those changes, things get slower again:

Benchmark                        (stopStage)  Mode  Cnt   Score   Error  Units
SingleJavacBenchmark.compileHot     Generate    ss   10  15.832 ± 0.135   s/op

So surprisingly, they have an effect. So I've put them back into the PR.

> For example desugaring the stream in the FileInfo constructor ... reduces allocation

`<side-note>`

Argh, this is frustrating. _Are we supposed to use the `Stream` API to help improve code clarity, or avoid it to prevent slowdowns?_ I've seen it argued both ways...

`</side-note>`

Anyway, unstreaming the loop you suggested plus another one, plus the other stuff, yeilds this on my laptop:

Benchmark                        (stopStage)  Mode  Cnt   Score   Error  Units
SingleJavacBenchmark.compileHot     Generate    ss   10  14.932 ± 0.370   s/op

That is with [this patch](https://github.com/openjdk/jdk/compare/master...archiecobbs:816162e08f036d2c1613746d70481807dc8266ed). Let me know what you see on the allocation pressure front... thanks.

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

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