RFR: 8161203: ResourceBundle.getBundle performance regression

[Masayoshi Okutsu]

Hi Peter,

Thank you for your suggestion. Actually CacheKey is used for storing 
information required to load resource bundles during a 
ResourceBundle.getBundle call. The current CacheKey usage may be too 
tricky and cause some maintenance problems. I will file a separate issue 
on that problem. I wanted to work on some clean up of the CacheKey 
usage, but I haven't had a chance.

Thanks,
Masayoshi


On 7/21/2016 10:13 PM, Peter Levart wrote:
> Hi Masayoshi,
>
> Previously the CacheKey::clone() method cleared a reference to 
> 'providers' in the clone making the provides unreachable from the 
> clone and making the clone unable to obtain providers. Now you also 
> reset the 'providersChecked' flag which makes the clone be able to 
> re-obtain the providers. This is dangerous as the clone is used as a 
> key in the cache and is strongly reachable from the cache. A slight 
> future modification of code could unintentionally produce a class 
> loader leak. To prevent that, I would somehow mark the clone so that 
> any attempt to invoke getProviders() on the clone would throw 
> IllegalStateException.
>
> Regards, Peter
>
> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote:
>> Hi,
>>
>> Please review the fix for JDK-8161203. The fix is to lazily load 
>> ResourceBundleProviders. It's not necessary to load providers before 
>> cache look-up.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8161203
>>
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01
>>
>> Thanks,
>> Masayoshi
>>
>