This sounds like a very interesting proposal. If we can split up the constructor, we might be able to merge the two separate yes replacement (constructor) and no replacement (NoRepl) implementations into one down the road.
I saw the PR https://github.com/openjdk/jdk/pull/25290, and from the diff (when Hide Whitespace is chosen), I see the change does bring much more consistency. Chen ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.org> on behalf of wenshao <shaojin.we...@alibaba-inc.com> Sent: Sunday, May 18, 2025 10:51 AM To: core-libs-dev <core-libs-dev@openjdk.org> Subject: C2 inlining failed because the String constructor is too large 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 ```java String(Charset charset, byte[] bytes, int offset, int length) {} ``` This is an important method that is called frequently. Breaking it into small methods does not require changing the code logic and is easy to accomplish. It is the easiest gain with minimal impact. I suggest solving this problem in JDK 25.
