Pushed. Xuelei, would you like to do the paperwork for the follow-on jdk8 backport?
On Fri, May 13, 2016 at 4:58 PM, Xuelei Fan <xuelei....@oracle.com> wrote: > 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. >>>>>>>>> >>>>>>> >>>>> >>> >
