RFR: 8311220: Optimization for StringLatin UpperLower [v4]

[Claes Redestad]

On Fri, 1 Sep 2023 18:44:13 GMT, 温绍锦 <duke at openjdk.org> wrote:

>> # Benchmark Result
>> 
>> 
>> sh make/devkit/createJMHBundle.sh
>> bash configure --with-jmh=build/jmh/jars
>> make test TEST="micro:java.lang.StringUpperLower.*"
>> 
>> 
>> 
>> ## 1. [aliyun_ecs_c8i.xlarge](https://help.aliyun.com/document_detail/25378.html#c8i)
>> * cpu : intel xeon sapphire rapids (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  27.180 ± 0.017  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  47.196 ± 0.066  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  32.307 ± 0.072  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  44.005 ± 0.414  ns/op
>> -StringUpperLower.upperToLower  avgt   15  32.310 ± 0.033  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  42.053 ± 0.341  ns/op
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 01)
>> +StringUpperLower.lowerToLower  avgt   15  16.964 ± 0.021  ns/op (+60.96%)
>> +StringUpperLower.lowerToUpper  avgt   15  46.491 ± 0.036  ns/op (+1.51%)
>> +StringUpperLower.mixedToLower  avgt   15  35.947 ± 0.254  ns/op (-10.12%)
>> +StringUpperLower.mixedToUpper  avgt   15  41.976 ± 0.326  ns/op (+4.83%)
>> +StringUpperLower.upperToLower  avgt   15  33.466 ± 4.036  ns/op (-3.45%)
>> +StringUpperLower.upperToUpper  avgt   15  17.446 ± 1.036  ns/op (+141.04%)
>> 
>> +Benchmark                      Mode  Cnt   Score   Error  Units (Update 00)
>> +StringUpperLower.lowerToLower  avgt   15  16.976 ± 0.043  ns/op (+60.160)
>> +StringUpperLower.lowerToUpper  avgt   15  46.373 ± 0.086  ns/op (+1.77%)
>> +StringUpperLower.mixedToLower  avgt   15  32.018 ± 0.061  ns/op (+0.9%)
>> +StringUpperLower.mixedToUpper  avgt   15  42.019 ± 0.473  ns/op (+4.72%)
>> +StringUpperLower.upperToLower  avgt   15  32.052 ± 0.051  ns/op (+0.8%)
>> +StringUpperLower.upperToUpper  avgt   15  16.978 ± 0.190  ns/op (+147.69%)
>> 
>> 
>> ## 2. [aliyun_ecs_c8a.xlarge](https://help.aliyun.com/document_detail/25378.html#c8a)
>> * cpu : amd epc genoa (x64)
>> 
>> ``` diff
>> -Benchmark                      Mode  Cnt   Score   Error  Units (baseline)
>> -StringUpperLower.lowerToLower  avgt   15  22.164 ± 0.021  ns/op
>> -StringUpperLower.lowerToUpper  avgt   15  46.113 ± 0.047  ns/op
>> -StringUpperLower.mixedToLower  avgt   15  28.501 ± 0.037  ns/op
>> -StringUpperLower.mixedToUpper  avgt   15  38.782 ± 0.038  ns/op
>> -StringUpperLower.upperToLower  avgt   15  28.625 ± 0.162  ns/op
>> -StringUpperLower.upperToUpper  avgt   15  27.960 ± 0.038  ns/op
>> 
>> +B...
>
> 温绍锦 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use hex literal

The two odd codepoints I was curious about are `0xaa` and `0xba`, both of which are lower-case according to `Character.isLowerCase(..)` but does not actually have an uppercase. The Unicode data categorize these two as `Lo`, Letter, other, so I'm a little confused how they got tagged as lowercase. 

`Character.toUpperCaseEx` is specified as adhering to the definition of the unicode data (unlike some legacy java character definition that might differ subtly) so perhaps it's reasonable to specify this newly invented `isLowerCaseEx` as strictly adhering to the unicode data in which case I think `0xaa` and `0xbb` should not be considered lower case. I am not a domain expert and would like someone like @naotoj to weigh in here. But either way we should think about how to specify this kind of method to keep it precise. Even if it's only internal code..

I suggested `hasUpperCase` (or maybe `hasUpperCaseEx`) as a way out of this particular conundrum, since it makes perfect sense to define a method named like that to be equivalent to `return cp != CharacterDataLatin1.instance.toUpperCaseEx(cp);`

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

PR Comment: https://git.openjdk.org/jdk/pull/14751#issuecomment-1704294149