RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v2]

[Naoto Sato]

On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ±  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ± 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ± 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ± 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pull values() into a var

Looks good. Glad we fixed the performance regression, and kudos to the bug submitter

src/java.base/share/classes/java/text/MessageFormat.java line 1993:

> 1991: 
> 1992:         // Returns a FormatStyle corresponding to the input text
> 1993:         // DEFAULT is the empty String, the pre-defined styles are 1-1 with their

The comment could mention that pre-defined ones are lower case ones of the enum names, but compared with the input styles ignoring cases for historical reasons

-------------

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3573794462
PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615745186