<i18n dev> RFR: 8365186: Reduce size of j.t.f.DateTimePrintContext::adjust [v3]

[Shaojin Wen]

On Sun, 10 Aug 2025 02:31:42 GMT, Chen Liang <liach at 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