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