RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

[Peter Levart]

Hi Chris,

While Attribute.Name.equals() should be comparably fast, what about 
Attribute.Name.hashCode() ? Could you for example extend the 
AvailableCharsetsCompare benchmark with a a @Setup method that 
constructs (via Attributes.putValue(String, String)) a 
java.util.jar.Attributes instance with available charsets as keys, then 
a @Benchmark method that traverses the Attributes instance looking-up 
each available charset via the Attributes.getValue(String) ... Just to 
see the relative amount of regression that might be caused by 
constructing intermediate lowercase String(s)...

Regards, Peter

On 03/08/2016 12:10 PM, Chris Hegarty wrote:
> … and the links:
>
>    http://cr.openjdk.java.net/~chegar/8151384/webrev.02/
>    http://cr.openjdk.java.net/~chegar/8151384/bench.02/
>
> -Chris.
>
> On 8 Mar 2016, at 11:07, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> On 7 Mar 2016, at 22:36, Xueming Shen <xueming.shen at oracle.com> wrote:
>>
>>> 515                 hashCode = name.toLowerCase(Locale.ROOT).hashCode();
>> Fixed.
>>
>> On 7 Mar 2016, at 22:20, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>>
>>> Hi Chris,
>>>
>>> On 03/08/2016 12:55 AM, Chris Hegarty wrote:
>>>> Updated links:
>>>> http://cr.openjdk.java.net/~chegar/8151384/webrev.01/
>>> *) Your previous patch had the explicit access to
>>> CharacterDataLatin1.instance.(toLowerCase|toUpperCase). Any reason not
>>> to use it in your new patch? Probably saves a shift and branch on a hot
>>> path -- j.l.String is one of those magical places where it actually matters.
>> I added this back for Latin1 compareToCI, which seems the most common
>> path.
>>
>>> Otherwise looks good.
>> Thanks.
>>
>>>> http://cr.openjdk.java.net/~chegar/8151384/bench.01/
>>> *) This one worries me a little bit. ASCIICaseInsensitive has the
>>> anomalous 360 us/op result in one of the forks, and that "best" is
>>> better than average StringCaseInsensitive:
>>>
>>> http://cr.openjdk.java.net/~chegar/8151384/bench.01/AvailableCharsetsCompare_afterChanges.txt
>>>
>>> This might be the genuine run-to-run variance with compiling the hot
>>> loop; I'd recommend using Blackhole.consume, not the accumulator
>>> variable to try avoiding that.
>> Blackhole added.  The results show that the ASCII version is marginally better,
>> even after the changes, but I suspect this can be further optimised in the future.
>>
>>> Otherwise looks good.
>> -Chris.
>>