RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

[Sergey Bylokhov]

On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redestad at 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