I have a new simpler webrev following your suggestion: http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/ 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. >>>>> >>> >
