RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
Sergey Chernyshev
github.com+6394632+sercher at openjdk.java.net
Sun Jul 25 12:10:07 UTC 2021
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:
> Dear colleagues,
>
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
>
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
>
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
>
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixed the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
>
> 
>
> 
>
> (update: added ZGC graphs)
>
> 
>
> 
>
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
>
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
>
> The patch was tested w/hotspot/tier1/tier2 test groups.
Hi Rémi,
>
> I don't understand your analysis, you are testing the startup time with -Xint which disable JITs, but there is no mention of -Xint in the bug report.
> It's obvious to me that there is a regression with -Xint given that the lambda creation is using invokedynamic which is only optimizable by JITs.
I apologize, perhaps I wasn't quite clear describing the analysis. Also, there was a faulty picture, -Xint was only used to grab the opcode traces to build the flamegraphs. I replaced the faulty image and posted additional graphs with -XX:+UseZGC.
Performance (startup) testing, as well as the live objects dumps were obtained with JIT enabled and with G1GC and ZGC. Would you think more data is needed with -Xint? (in addition to the flamegraphs which are obtained with -Xint)
>
> I think you should first try to reproduce the issue with the correct flags and then follow the advice from Mandy on how to implement the fix.
In my opinion removing computeXXX methods defeats the purpose of the entire deadlock fix. It is sufficient to avoid using lambdas in order not to trigger the method handles initialization, which is what Mandy Chung is really suggesting in the first note in [JBS](https://bugs.openjdk.java.net/browse/JDK-8270321).
>
> Using an anonymous class may introduce more allocation than using a lambda once the code is JITed.
I provided live objects dumps after noop.jar has been loaded with JIT enabled. Please see the attached histograms. The difference is always the same after full GC (1000 bytes in 12 objects compared to pre JDK-8266310 version tested w/G1) and it doesn't change with subsequent executions. The patch resolves the memory regression as you may observe in RSS graphs and heap dumps. Please see 'fixed.histogram' in comparison with the object dump before the fix (post JDK-8266310) in 'original.histogram'.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4893
More information about the core-libs-dev
mailing list