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