On Fri, 2 May 2025 03:55:24 GMT, Shaojin Wen <s...@openjdk.org> wrote:
>> The byte[] allocated in Integer/Long.toString is fully filled, so we can use
>> StringConcatHelper::newArray to create byte[] to improve performance.
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23353#discussion_r2071969862
