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

[Chris Hegarty]

Hi Peter,

On 9 Mar 2016, at 08:42, Peter Levart <peter.levart at gmail.com> wrote:

> 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)…

Just for clarification, the change in java.util.jar.Attributes has nothing to do 
with the charsets. Attributes stores the individual attributes from the Jar 
Manifest. There are only a relatively small number of standard Attributes [1].

When digging through old history to try to find out why java.util.jar.Attributes
was ever using ASCIICaseInsensitiveComparator, it was not clear that
performance was the motivation. It seemed to be a knock on effect of the
use of the comparator ( which was trying to avoid the continuous allocation
cost to toLowerCase during comparisons ). I don’t think this code is particularly
performance sensitive, and especially not hashCode.

Maybe a benchmark with a number of standard Jar file attributes would make
sense?

-Chris.

[1] http://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes