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

[Xuelei Fan]

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.
>>>>
>>