On Sun, 10 Aug 2025 02:31:42 GMT, Chen Liang <li...@openjdk.org> wrote:
>> In theory, the smaller the method, the greater the opportunity for >> performance improvement, but in DateTimeFormatterWithPaddingBench and >> DateTimeFormatterBench, the improvement is the same. > > This depends on how often Formatters override chrono and zone, and how often > these overrides are no-op so we can still fast return. if both shortcuts are > significant, it may well be reasonable to set up a series of small shortcut > methods and end with a "slow tail" (See the example of `ClassValue::get`, > `getFromBackup`, and `getFromHashMap`). > > Given that example, I recommend renaming the two new split `adjust` into > `adjustWithOverride` and `adjustSlow` to distinguish from the actual `adjust` > method. > > In addition, I agree with @jodastephen that line 130 intuitively seems like > the best place to break methods. Do you know if the "if have zone and > instant" case is so frequent that it should be included in the 2nd method > instead of the 3rd? The goal of inlining, as far as I know, is to include > minimal hot code to be compiled, instead of tweaking the method size so it > exactly falls into FreqInlineSize, so the less code to compile for C2 the > better and faster it compiles. The `adjust` method has a code size of 27, covering the most common scenarios and capable of handling C1. The `adjustWithOverride` method has a code size of 123, which can also be handled by C2 and covers the use of formatters with zones in the DateTimeFormatterBench. This split ensures a balanced approach to startup performance and optimizations for the most common scenarios. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26633#discussion_r2265116221
