8357289: Break down the String constructor into smaller methods

[wenshao]

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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8357289: Break down the String constructor into smaller methods (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25290/head:pull/25290
$ git checkout pull/25290

Update a local copy of the PR:
$ git checkout pull/25290
$ git pull https://git.openjdk.org/jdk.git pull/25290/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25290

View PR using the GUI difftool:
$ git pr show -t 25290

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25290.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back swen! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@wenshao The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[wenshao]

Below are the performance numbers on the MacBook M1 Max. The numbers show that after the small split method, the performance has been significantly improved.

-# master 6c42856b8d5
-Benchmark                                                  (size)  Mode  Cnt   Score   Error  Units
-StringConstructor.newStringFromBytes                            7  avgt   15   6.628 ± 0.048  ns/op
-StringConstructor.newStringFromBytes                           64  avgt   15  10.182 ± 0.079  ns/op
-StringConstructor.newStringFromBytesRanged                      7  avgt   15  10.187 ± 0.871  ns/op
-StringConstructor.newStringFromBytesRanged                     64  avgt   15  11.304 ± 0.111  ns/op
-StringConstructor.newStringFromBytesRangedWithCharsetUTF8       7  avgt   15  10.869 ± 0.753  ns/op
-StringConstructor.newStringFromBytesRangedWithCharsetUTF8      64  avgt   15  11.348 ± 0.134  ns/op
-StringConstructor.newStringFromBytesWithCharsetNameUTF8         7  avgt   15   9.483 ± 0.119  ns/op
-StringConstructor.newStringFromBytesWithCharsetNameUTF8        64  avgt   15  12.755 ± 0.089  ns/op
-StringConstructor.newStringFromBytesWithCharsetUTF8             7  avgt   15   6.721 ± 0.107  ns/op
-StringConstructor.newStringFromBytesWithCharsetUTF8            64  avgt   15  10.208 ± 0.065  ns/op


+# current 4ebac0ddc64
+Benchmark                                                  (size)  Mode  Cnt   Score   Error  Units
+StringConstructor.newStringFromBytes                            7  avgt   15   4.715 ± 0.029  ns/op +40.57%
+StringConstructor.newStringFromBytes                           64  avgt   15   8.019 ± 0.152  ns/op +26.97%
+StringConstructor.newStringFromBytesRanged                      7  avgt   15   5.563 ± 0.059  ns/op +83.12%
+StringConstructor.newStringFromBytesRanged                     64  avgt   15   9.549 ± 0.217  ns/op +18.37%
+StringConstructor.newStringFromBytesRangedWithCharsetUTF8       7  avgt   15   5.579 ± 0.076  ns/op +94.81%
+StringConstructor.newStringFromBytesRangedWithCharsetUTF8      64  avgt   15   9.407 ± 0.047  ns/op +20.63%
+StringConstructor.newStringFromBytesWithCharsetNameUTF8         7  avgt   15   8.168 ± 0.084  ns/op +16.09%
+StringConstructor.newStringFromBytesWithCharsetNameUTF8        64  avgt   15  12.574 ± 0.268  ns/op + 1.43%
+StringConstructor.newStringFromBytesWithCharsetUTF8             7  avgt   15   4.722 ± 0.043  ns/op +42.33%
+StringConstructor.newStringFromBytesWithCharsetUTF8            64  avgt   15   8.077 ± 0.144  ns/op +26.38%

[mlbridge]

Webrevs

• 02: Full - Incremental (fab7728b)
• 01: Full - Incremental (b6f0a2db)
• 00: Full (f7abb552)

[minborg]

I wonder if it would be better to first check COMPACT_STRINGS in a first-level if and then branch off to separate support methods? Looking at the comments near the declaration of COMPACT_STRINGS, this might provide additional benefits.

[wenshao]

I wonder if it would be better to first check COMPACT_STRINGS in a first-level if and then branch off to separate support methods? Looking at the comments near the declaration of COMPACT_STRINGS, this might provide additional benefits.

Now all the broken methods have CodeSize < 325 and can be inlined by C2. If we check COMPACT_STRINGS at the first level, we need to change more. I want to achieve the goal with minimal changes.