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

[Martin Buchholz]

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