On Mon, 26 May 2025 19:20:06 GMT, Shaojin Wen <s...@openjdk.org> wrote:
>> Through JVM Option +PrintInlining, we found that String has a constructor
>> codeSize of 852, which is too large. This caused failed to inline.
>>
>> The following is the output information of PrintInlining:
>>
>> @ 9 java.lang.String::<init> (12 bytes) inline (hot)
>> !m @ 1 java.nio.charset.Charset::defaultCharset (52 bytes)
>> inline (hot)
>> ! @ 8 java.lang.String::<init> (852 bytes) failed to
>> inline: hot method too big
>>
>>
>> In Java code, the big method that cannot be inlined is the following
>> constructor
>>
>>
>> String(Charset charset, byte[] bytes, int offset, int length) {}
>>
>> The above String constructor is too large; break it down into smaller
>> methods with a codeSize under 325 to allow them to be inlined by the C2.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> from @liach
Seems like a straightforward refactoring but there should be a comment
indicating that what looks like the creation of additional Strings as short
lived objects is mitigated by C2 optimizing across method calls with escape
analysis.
It might be helpful to re-test startup time. The interpreter will be creating
all those strings and they won't be optimized away.
src/java.base/share/classes/java/lang/String.java line 613:
> 611: return new String(utf16, UTF16);
> 612: }
> 613: else { // !COMPACT_STRINGS
Join the `else` with the line above.
-------------
PR Review: https://git.openjdk.org/jdk/pull/25290#pullrequestreview-2955447311
PR Review Comment: https://git.openjdk.org/jdk/pull/25290#discussion_r2164969688
