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