C2 inlining failed because the String constructor is too large

[Chen Liang]

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-retn at openjdk.org> on behalf of wenshao <shaojin.wensj at alibaba-inc.com>
Sent: Sunday, May 18, 2025 10:51 AM
To: core-libs-dev <core-libs-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250518/19ecbd53/attachment.htm>