RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator
Chris Hegarty
chris.hegarty at oracle.com
Wed Mar 9 13:44:42 UTC 2016
On 9 Mar 2016, at 13:03, Claes Redestad <claes.redestad at oracle.com> 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.
>
> 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.
Not any more ( it is no longer with us )!!
Interesting… let me know if you issues once this change makes its
way into a promoted build, or during your performance investigations.
BTW. I am not against doing something “smarter” for Attributes.hashCode.
I just didn’t think it was relevant, or performance sensitive, any more.
-Chris
More information about the core-libs-dev
mailing list