RFR 8222955 : Optimize String.replace(CharSequence, CharSequence) for Latin1 encoded strings

[Ivan Gerasimov]

Hi Claes!


On 4/25/19 4:51 AM, Claes Redestad wrote:
> Hi Ivan,
>
> the changes and fast-path speed-ups look reasonable, but I'd like to see
> that the overhead for cases not helped by the fast paths isn't
> excessive, e.g., micro variants with UTF16 Strings and a mix of Latin1
> and UTF16.
>
Good point!  After adding a few more micro-benchmarks with UTF16 
strings, I realized that it can actually make sense to improve the 
UTF16/mixed branch as well.

I'll send the updated webrev shortly.

With kind regards,
Ivan

> /Claes
>
> On 2019-04-25 08:00, Ivan Gerasimov wrote:
>> Hello!
>>
>> This enhancement was inspired by a recent discussion at 
>> compiler-dev at openjdk.java.net.
>>
>> It seems to be a non-uncommon situation when String.replace(CS, CS) 
>> is called with this and both arguments being Latin1 strings, so it 
>> seems reasonable to optimize for such case.
>>
>> Here are the fresh benchmark results (see the webrev for the source 
>> of the benchmark):
>> -- prior the fix:
>> Benchmark                 Mode  Cnt   Score   Error  Units
>> StringReplace.replace1_0  avgt   24  70.860 ± 5.239  ns/op
>> StringReplace.replace1_1  avgt   24  82.661 ± 1.007  ns/op
>> StringReplace.replace1_2  avgt   24  97.251 ± 1.186  ns/op
>>
>> -- after the fix:
>> Benchmark                 Mode  Cnt   Score   Error  Units
>> StringReplace.replace1_0  avgt   24  52.855 ± 0.982  ns/op
>> StringReplace.replace1_1  avgt   24  23.849 ± 0.066  ns/op
>> StringReplace.replace1_2  avgt   24  62.266 ± 0.552  ns/op
>>
>> So the speedup was x1.3, x3.4, x1.5.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8222955
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8222955/00/webrev/
>>
>> Mach5 job is in progress and looks green so far (a few test groups 
>> are left).
>>
>> Thanks in advance!
>>
>

-- 
With kind regards,
Ivan Gerasimov