• Type: Bug
• Component: hotspot
• Sub-Component: compiler
• Affected Version: 26

• Priority: P3
• Status: Open
• Resolution: Unresolved

• Submitted: 2025-10-03
• Updated: 2025-11-11

JDK 26
26Unresolved

I would suspect that's an inlining issue of some sort because of the compilation ordering. 11-11-2025 [~iveresov] Any thoughts on this? 10-11-2025 > Could anyone check if that makes the regression disappear? Seems to be driven by Tier3LoadFeedback: # Mainline ClassfileBenchmark.parse thrpt 25 92709,788 ± 428,623 ops/s # -XX:Tier3LoadFeedback=0 ClassfileBenchmark.parse thrpt 25 96635,019 ± 674,997 ops/s # -XX:Tier4LoadFeedback=0 ClassfileBenchmark.parse thrpt 25 92646,863 ± 134,687 ops/s # -XX:Tier3LoadFeedback=0 -XX:Tier4LoadFeedback=0 ClassfileBenchmark.parse thrpt 25 96036,495 ± 645,496 ops/s 21-10-2025 Unassigning myself since I don't have the hardware to reproduce this issue. This issue seems minor since only a single microbenchmark on a single OS is affected so far. 20-10-2025 I don't have direct access to a Mac, and cannot reproduce the regression on an x86_64 Linux. I tried "-f 10" as [~shade] did. JDK-8368071 essentially restores the logic from `CompilationPolicy::threshold_scale()` relevant to -XX:Tier3LoadFeedback and -XX:Tier4LoadFeedback. CompilationPolicy::threshold_scale()` could increase compile thresholds, thus fewer methods may be compiled, or they could be compiled at a later time. The logic in `CompilationPolicy::threshold_scale()` was originally introduced in JDK-7020403 and JDK-8012371. I did some investigation on x86_64 Linux by checking code cache usage and output from -XX:+LogCompilation. There is plenty of free space in code cache, and the number of compiled methods are similar before and after JDK-8368071. Most methods are indeed compiled during warmup iterations. Thus it remains a puzzle why it could cause regression on Mac. `-XX:Tier3LoadFeedback=0 -XX:Tier4LoadFeedback=0` should disable the logic in `CompilationPolicy::threshold_scale()`. Could anyone check if that makes the regression disappear? 20-10-2025 Thanks! Managed to reproduce a similar regression on my M1: % build/macosx-aarch64-server-release/images/jdk/bin/java -jar benchmarks.jar ClassfileBenchmark.parse -f 10 # Mainline ClassfileBenchmark.parse thrpt 15 92529,901 ± 444,051 ops/s # At patch (bdfe05b595d) ClassfileBenchmark.parse thrpt 50 92775,039 ± 266,686 ops/s # Before the patch (bdfe05b595d~1) ClassfileBenchmark.parse thrpt 50 96056,722 ± 484,648 ops/s 09-10-2025 [~shade] please see attached plot. 09-10-2025 Have not tried on Mac yet. But on my 5950X, Linux, 8 core config, I see no regression and I note the benchmark has a very high run-to-run variance in itself. It is curious no other benchmarks are affected the same way. So, how sure are we this performance regression is real? $ taskset -c 0-7 build/linux-x86_64-server-release/images/jdk/bin/java -jar benchmarks.jar ClassfileBenchmark.parse -f 3 # mainline ClassfileBenchmark.parse thrpt 15 64903.474 ± 996.457 ops/s # bdfe05b595d86c62f7dad78549023a3426423679 ClassfileBenchmark.parse thrpt 15 64366.029 ± 463.450 ops/s # bdfe05b595d86c62f7dad78549023a3426423679~1 ClassfileBenchmark.parse thrpt 15 64704.892 ± 1655.968 ops/s 09-10-2025 Could be related to JDK-8368321 ([~iveresov]). ILW = Performance regression (2-3%), with single microbenchmark, no known workaround but potentially using different values for Tier*ProfileDelayFactor = HLM = P3 06-10-2025 [~manc] Could you please have a look? [~iveresov], [~shade], FYI. 06-10-2025