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

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Mar 7 22:20:39 UTC 2016


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.

Otherwise looks good.

>   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.

Otherwise looks good.

Thanks,
-Aleksey




More information about the core-libs-dev mailing list