On 5/14/2016 3:50 AM, Martin Buchholz wrote: > Hi Xuelei, > > The jdk9 version is still up in the air. I propose committing: > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/ > Looks fine to me. Thanks!
Xuelei > On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan <xuelei....@oracle.com> wrote: >> 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. >>>>>>>> >>>>>> >>>> >>
