RFR: 8301958: Avoid Arrays.copyOfRange overhead in java.lang.String [v5]

[Claes Redestad]

On Tue, 7 Feb 2023 19:08:59 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   copyrights
>
> src/java.base/share/classes/java/lang/String.java line 698:
> 
>> 696:     }
>> 697: 
>> 698:     static byte[] copyBytes(byte[] bytes, int offset, int length) {
> 
> Given that the stub generated for array copy seems highly dependent by the call site constrains, did you tried adding a check for offset == 0 and/or length == bytes.length?
> 
> If (offset == 0 && bytes.length == length) {
>     System.arrayCopy(bytes, 0, dst, 0, bytes.length);
>     // etc etc the other combinations 
> 
> This should have different generated stubs with much smaller ASM depending by the enforced constrains (and shouldn't affect terribly the code size of the method, given that the stub won't be inlined AFAIK)
> 
> Beware, as noted by others, I'm not suggesting that's the way to fix this, but it would be interesting to check how much perf we leave on the ground due to the this supposed "inefficient" stub generation (if that's the issue).

I did some quick experiments but saw no clear win from doing anything like this here. Feel free to experiment and see if there's some particular configuration that comes out ahead.

FTR I did not intend for this RFE to solve https://bugs.openjdk.org/browse/JDK-8295496 completely, but provide a small, partial win that might possibly clear a path to solving that likely orthogonal issue.

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

PR: https://git.openjdk.org/jdk/pull/12453