RFR: 8349176: Speed up Integer/Long.toString via StringConcatHelper::newArray [v3]

[Shaojin Wen]

On Fri, 2 May 2025 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into allocate_un_init_202501
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/Integer.java
>>    #	src/java.base/share/classes/java/lang/Long.java
>>  - use StringConcatHelper.newArray
>>  - simplify
>>  - use Unsafe.allocateUninitializedArray
>>  - revert StringConcatHelper newArray change
>>  - copyright
>>  - remove duplicate check
>>  - allocateUninitializedArray
>
> src/java.base/share/classes/java/lang/Integer.java line 439:
> 
>> 437:             return new String(buf, LATIN1);
>> 438:         } else {
>> 439:             byte[] buf = StringConcatHelper.newArray(size << 1);
> 
> @RogerRiggs I recommended StringConcatHelper because that was used in StringLatin1.
> 
> For StringUTF16, it has its own newBytesFor:
> Suggestion:
> 
>             byte[] buf = StringUTF16.newBytesFor(size);
> 
> Or we can factor out a `StringLatin1.newBytesFor` too and encapsulate `newArray` usage.

public static byte[] newBytesFor(int len) {
        return new byte[newBytesLength(len)];
    }

StringUTF16.newBytesFor uses new byte[], which is not the purpose of this PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071982990