RFR: JDK-8156584: Initialization race in sun.security.x509.AlgorithmId.get

[Xuelei Fan]

On 5/13/2016 3:00 AM, Martin Buchholz wrote:
> I have a new simpler webrev following your suggestion:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
Looks fine to me.

Thanks,
Xuelei

> Old one available at
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race.0/
> 
> On Wed, May 11, 2016 at 11:41 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> Hi Martin,
>>
>> If you agree with the update, I will sponsor your contribution for the
>> testing and integration for JDK 9.
>>
>> Thanks,
>> Xuelei
>>
>> On 5/12/2016 2:27 PM, Martin Buchholz wrote:
>>> Xuelei,
>>>
>>> I again invite you to take ownership of this change.
>>> It needs to be ported to jdk9.
>>>
>>> If we simply delete OidTableSize then the initialization code will be
>>> close to optimal for the default configuration, and it will still work
>>> well if configured a little differently, so I would keep it.  But we
>>> can also use the default initial capacity (16) if you prefer.
>>>
>>> On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>> On 5/12/2016 1:21 PM, Martin Buchholz wrote:
>>>>> Hi Xuelei,
>>>>>
>>>>> I think the non-test code will work well with any set of providers,
>>>>> but is optimized for the default set of providers.  If the user
>>>>> removes a provider, then the hashmap will be auto-compacted.  The
>>>>> OidTableSize test will fail if the default providers are changed, but
>>>>> that actually helps maintenance efforts (if you care about optimizing
>>>>> startup; it's also reasonable not to care, and to delete the
>>>>> OidTableSize test entirely).
>>>>>
>>>> The test is used to test JDK default providers, but not the application
>>>> customized configurations.  Application customized providers may be
>>>> different.  And the providers may also be different from platform to
>>>> platform.  So sometimes, the hard-coded size code may make the startup
>>>> performance worse.  For maintenance, even if the OidTableSize test
>>>> failed in the future, it may be hard to find the need to update the code
>>>> here.
>>>>
>>>> Xuelei
>>>>
>>>>> On Wed, May 11, 2016 at 9:33 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>>>> AlgorithmId.java
>>>>>> ================
>>>>>> Line 582-587, about the capacity of hash map, applications may customize
>>>>>> Security providers and more OID numbers may get removed/added later, so
>>>>>> the oid number may be not a fixed hard-coded number.  It may be easier
>>>>>> to maintain the code if using the default initial capacity of HashMap.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>>
>>>>>> On 5/12/2016 1:01 AM, Martin Buchholz wrote:
>>>>>>> Webrev updated.
>>>>>>> Still looking for crypto-collaborator.
>>>>>>>
>>>>>>> On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz <martinrb at google.com> wrote:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8156584
>>>>>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
>>>>>>>>
>>>>>>>> I'm not a crypto engineer, so I'm hoping someone on security-dev
>>>>>>>> adopts this fix.  But current webrev is intended to be a complete fix
>>>>>>>> for jdk8.
>>>>>>
>>>>
>>