No, I accidentally posted numbers for an apples to oranges comparison (-t 1 vs -t 4 on the same system). The final version does not differ in performance from this version when comparing like for like.
Hämta Outlook för Android<https://aka.ms/ghei36> ________________________________ From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of Sergey Bylokhov <s...@openjdk.java.net> Sent: Saturday, March 6, 2021 9:39:07 PM To: core-libs-...@openjdk.java.net <core-libs-...@openjdk.java.net>; i18n-dev@openjdk.java.net <i18n-dev@openjdk.java.net> Subject: Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2] On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redes...@openjdk.org> wrote: >> src/java.base/share/classes/java/util/Locale.java line 946: >> >>> 944: Locale loc = defaultDisplayLocale; // volatile read >>> 945: if (loc == null) { >>> 946: loc = getDisplayLocale(); >> >> Just interesting how did you check that the performance difference is >> because of volatile read, and not because of replacing of the switch by the >> "if"? > > I started out with this variant, only removing the double volatile reads: > > public static Locale getDefault(Locale.Category category) { > // do not synchronize this method - see 4071298 > Locale loc; > switch (category) { > case DISPLAY: > loc = defaultDisplayLocale; > if (loc == null) { > synchronized(Locale.class) { > loc = defaultDisplayLocale; > if (loc == null) { > loc = defaultDisplayLocale = initDefault(category); > } > } > } > return loc; > case FORMAT: > loc = defaultFormatLocale; > if (loc == null) { > synchronized(Locale.class) { > loc = defaultFormatLocale; > if (loc == null) { > loc = defaultFormatLocale = initDefault(category); > } > } > } > return loc; > default: > assert false: "Unknown Category"; > } > return getDefault(); > } > > Scores were the same: > Benchmark Mode Cnt Score Error Units > LocaleDefaults.getDefault avgt 5 10.045 ± 0.032 ns/op > LocaleDefaults.getDefaultDisplay avgt 5 11.301 ± 0.053 ns/op > LocaleDefaults.getDefaultFormat avgt 5 11.303 ± 0.054 ns/op > > I then refactored and checked that the refactorings were performance neutral. And it is faster than the final version? ------------- PR: https://git.openjdk.java.net/jdk/pull/2845
