RFR: 8221701: Archive constant BaseLocales

[Claes Redestad]

Hi Naoto,

thanks for reviewing!

On 2019-04-02 17:36, Naoto Sato wrote:
> Hi Claes,
> 
> Thank you for looking into this. I remember we discussed this before. 
> One comment I have is that, currently the archive map seems to have two 
> level structure, i.e, lang, then country. There is another basic element 
> that consists of a locale, that is script. At the moment, there is not a 
> constant that has script in it, but if we wanted to have a constant 
> locale, say zh-Hans, it cannot be archived. It's ok for now, but can it 
> be extended if we want in the future, without any compatibility 
> implications?

You're right that adding a constant with script would force a rewrite.
One alternative solution is to not use nested maps, but instead archive
an array of BaseLocales that we iterate over:

http://cr.openjdk.java.net/~redestad/8221701/open.01/

This has more boilerplate but is simpler in structure and I believe
easier to maintain. This is also significantly faster on startup than
the previous iteration (also when default Locale is not in the set of
predefined constants).

Performance of many repeated calls to new Locale/Locale.getInstance sees
a drop with either approach (from ~0.5us/op to ~0.7us/op on a new 
Locale("se", "SV") micro), but I believe creation of Locale objects are
unlikely to be on the critical path.

What do you think?

Thanks!

/Claes

> 
> Naoto
> 
> On 4/2/19 3:14 AM, Claes Redestad wrote:
>>
>>
>> On 2019-04-01 17:46, Claes Redestad wrote:
>>> Hi,
>>>
>>> by archiving constant BaseLocale objects, we can simplify (and speed up)
>>> creation of the constant Locale objects in java.util.Locale which are
>>> unconditionally created during startup.
>>>
>>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8221701
>>> Webrev: http://cr.openjdk.java.net/~redestad/8221701/open.00/
>>>
>>> Testing: tier1-3, along with patches for JDK-8221723 and
>>> JDK-8221724
>>
>> These RFEs have now been pushed, unblocking this RFE.
>>
>> /Claes