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