RFR 8072394: Performance improvement for X.509 certificate parsing

[Sean Mullan]

This fix looks fine, but I am trying to remember why a Set/LinkedHashSet 
was used in the first place, it seem like an List/ArrayList would have 
been more suitable. Even though PolicyInformation is an internal class, 
it's probably better to not change that detail at this point unless we 
have a better reason.

Can you add a noreg-perf label to the bug?

--Sean

On 02/03/2015 05:42 AM, Florian Weimer wrote:
> The sun.security.x509.PolicyInformation constructor creates
> java.security.cert.PolicyQualifierInfo instances and adds them to a
> LinkedHashSet. PolicyQualifierInfo does not override hashCode(), so the
> default implementation based on System.identityHashCode() is used, which
> is rather slow.
>
> I addressed this by implementing an explicit, identity-based hashCode()
> using an atomic counter.  Another approach would be to replace the
> LinkedHashSet with a Set backed by an ArrayList.
>
>    <http://cr.openjdk.java.net/~fweimer/8072394/webrev.00/>
>
> Before the change, this particular call to Object#hashCode() accounted
> for 25% of all hits in hprof.
>
> My benchmark involved parsing 1,000,000 certificates from the Google
> certificate transparency log.  The benchmark times includes loading the
> DER-encoded certificates from an SQLite database.  They are quite noisy
> because the X.509 parsing code allocates heavily.
>
> R says this about this change (run time is measured in seconds):
>
>> old <- c(50.246, 51.237, 50.057, 49.611, 49.895, 49.268, 50.161,
> 49.992, 49.972, 50.380)
>> new <- c(50.386, 50.628, 49.496, 49.196, 49.581, 49.845, 50.009,
> 49.229, 48.138, 48.762)
>> t.test(old, new)
>
> 	Welch Two Sample t-test
>
> data:  old and new
> t = 1.9356, df = 16.015, p-value = 0.07077
> alternative hypothesis: true difference in means is not equal to 0
> 95 percent confidence interval:
>   -0.05278151  1.16258151
> sample estimates:
> mean of x mean of y
>    50.0819   49.5270
>
>
>