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
We may have another case of optimizing for the JMH microbenchmark, and it would
be more valuable to see improvements in higher level benchmarks. Such as
DaCapo. BioJava.
Where is the most benefit of inlining? Inlinlining increases the code size of
the caller, but only results in a benefit if the resulting code can avoid some
code paths, accesses, or branches.
Smaller methods do give C2 more inlining options and can make the code more
readable or composable.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25290#issuecomment-3001659215
