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

[Xuelei Fan]

On 5/14/2016 3:50 AM, Martin Buchholz wrote:
> Hi Xuelei,
> 
> The jdk9 version is still up in the air.  I propose committing:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/
> 
Looks fine to me.   Thanks!

Xuelei

> On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> 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.
>>>>>>>>
>>>>>>
>>>>
>>