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

[Martin Buchholz]

Pushed.

Xuelei, would you like to do the paperwork for the follow-on jdk8 backport?

On Fri, May 13, 2016 at 4:58 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 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.
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>