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

[Peter Levart]

Hi Claes,

Here's the pre-post-patch comparison:

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

import java.util.concurrent.TimeUnit;
import java.util.jar.Attributes;

@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(1)
@State(Scope.Thread)
public class JarAttributesBench {

     /*

pre-patch:

Benchmark                            Mode  Cnt    Score    Error Units
JarAttributesBench.buildAttributes   avgt   10  814.876 ± 10.300 ns/op
JarAttributesBench.lookupAttributes  avgt   10  728.400 ±  4.005 ns/op

post-patch:

Benchmark                            Mode  Cnt    Score   Error Units
JarAttributesBench.buildAttributes   avgt   10  949.266 ± 8.422 ns/op
JarAttributesBench.lookupAttributes  avgt   10  890.683 ± 6.651 ns/op

     */

     private static final String[] keys = {
         "Manifest-Version", "Created-By", "Signature-Version",
         "Class-Path", "Main-Class"
     };

     private Attributes attributes;

     @Setup(Level.Trial)
     public void setup() {
         attributes = buildAttributes();
     }

     @Benchmark
     public Attributes buildAttributes() {
         Attributes attr = new Attributes();
         for (String key : keys) {
             attr.putValue(key, key);
         }
         return attr;
     }

     @Benchmark
     public void lookupAttributes(Blackhole bh) {
         Attributes attr = attributes;
         for (String key : keys) {
             bh.consume(attr.getValue(key));
         }
     }
}



... so nothing drastic.

On 03/09/2016 02:03 PM, Claes Redestad wrote:
>
>
> On 2016-03-09 13:17, Peter Levart wrote:
>>>
>>> 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.
>>
>> I guess looking-up a manifest attribute is not a performance critical 
>> operation, you are right. 
>
> Could this be an old startup optimization, since first call to 
> String.toLowerCase/toUpperCase will initialize and pull in 
> java.util.Locale and friends? If so it's probably not effective any more.

Could be, yes.

>
> Coincidentally - due to a recent regression - we're currently spending 
> quite a bit of time parsing manifests of all jar files on the 
> classpath, making ASCIICaseInsensitiveComparator show up prominently 
> in some startup profiles.
>
> /Claes


Regards, Peter