We noticed a large startup performance regression for -XX:+TieredCompilation when comparing JDK 25 vs JDK 21. This regression is obvious and severe for extremely large applications. In our case, the application sets -XX:CICompilerCount=12, and may compile >750K methods in the first hour after startup with JDK 21. With JDK 25, it only compiles ~370K methods in the first hour. In addition, with JDK 25 it takes 8 hours to warm up this application to the same level (in terms of code cache usage and overall throughput) as JDK 21 could do in 1 hour. Performance suffers badly in the first 8 hours because much more code is interpreted instead of JIT compiled.

We also noticed a relevant regression in time spent in compilation (reported by java.ci.totalTime hsperfdata counter) for a separate, moderate-size application. java.ci.totalTime increased by 10-20% with JDK 25, but this application did not notice obvious regression in startup or throughput.

We found the culprit is JDK-8355003. In particular, the change in `CompilationPolicy::common()` that switched `Predicate::apply()` to `Predicate::apply_scaled()` with a scale of 1.0.

`LoopPredicate::apply` and `CallPredicate::apply` are quite different from `LoopPredicate::apply_scaled` and `CallPredicate::apply_scaled`. `apply_scaled` does not have the logic in `CompilationPolicy::threshold_scale()` to adjust the scale based on code cache usage and compilation queue size.