CI Build by build tracking seems to show it's related to JDK-8290025.
Comments
We accept this regression as a by-product of JDK-8290025 which brings other benefits.
17-10-2022
[~ecaspole] Are you okay with closing this?
17-10-2022
Yeah I think so unless somebody objects.
13-10-2022
Should we close this as Won't Fix then?
13-10-2022
Indeed. We don’t have much choice unless we intend to not use loom. And as I said, when I ran the same perf tests with and without the sweeper removal patches, the difference was not significant in aurora. If there is any significance in the regression, I think we might have to just accept it.
12-10-2022
Is this the overhead of the nmethod entry barriers?
If so, the regression should not exist in cases were the nmethod entry barriers were already used (Loom, ZGC, ShenandoahGC). So, it's already included in the price we have to pay for Loom or ultra-low latency GC.
We also noticed performance regression with G1 on PPC64 which is mitigated, but not completely fixed by JDK-8295069.
12-10-2022
Hmm. Before I upstreamed the sweeper removal, I ran everything through Aurora because I didn’t want any surprises like these. It then reported -1.46% performance on that benchmark on x86 and -1.36% on AArch64, but they were both statistically insignificant.
22-09-2022
Erik, could you please have a look?
22-09-2022
ILW = small performance regression; on one benchmark; no workaround = MMH = P3