Re: RFR: 8156071: List.of: reduce array copying during creation
On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks wrote: > Plumb new internal static factory method to trust the array passed in, > avoiding unnecessary copying. JMH results for > the benchmark show about 15% improvement for the cases that were optimized, > namely the 3 to 10 fixed arg cases. > # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview > -verbose:gc -XX:+UsePara > llelGC -Xms4g -Xmx4g -Xint > # Warmup: 5 iterations, 1 s each > # Measurement: 5 iterations, 2 s each > > WITHOUT varargs optimization: > > Benchmark Mode Cnt Score Error Units > ListArgs.list00 thrpt 15 6019.539 ± 144.040 ops/ms > ListArgs.list01 thrpt 15 1985.009 ± 40.606 ops/ms > ListArgs.list02 thrpt 15 1854.812 ± 17.488 ops/ms > ListArgs.list03 thrpt 15 963.866 ± 10.262 ops/ms > ListArgs.list04 thrpt 15 908.116 ± 6.278 ops/ms > ListArgs.list05 thrpt 15 848.607 ± 16.701 ops/ms > ListArgs.list06 thrpt 15 822.282 ± 8.905 ops/ms > ListArgs.list07 thrpt 15 780.057 ± 11.214 ops/ms > ListArgs.list08 thrpt 15 745.295 ± 19.204 ops/ms > ListArgs.list09 thrpt 15 704.596 ± 14.003 ops/ms > ListArgs.list10 thrpt 15 696.436 ± 4.914 ops/ms > ListArgs.list11 thrpt 15 661.908 ± 11.041 ops/ms > > WITH varargs optimization: > > Benchmark Mode Cnt ScoreError Units > ListArgs.list00 thrpt 15 6172.298 ± 62.736 ops/ms > ListArgs.list01 thrpt 15 1987.724 ± 45.468 ops/ms > ListArgs.list02 thrpt 15 1843.419 ± 10.693 ops/ms > ListArgs.list03 thrpt 15 1126.946 ± 30.952 ops/ms > ListArgs.list04 thrpt 15 1050.440 ± 17.859 ops/ms > ListArgs.list05 thrpt 15 999.275 ± 23.656 ops/ms > ListArgs.list06 thrpt 15 948.844 ± 19.615 ops/ms > ListArgs.list07 thrpt 15 897.541 ± 15.531 ops/ms > ListArgs.list08 thrpt 15 853.359 ± 18.755 ops/ms > ListArgs.list09 thrpt 15 826.394 ± 8.284 ops/ms > ListArgs.list10 thrpt 15 779.231 ± 4.104 ops/ms > ListArgs.list11 thrpt 15 650.888 ± 3.948 ops/ms Looks good, i wondered why the performance results were so slow then i looked more closely and saw "-Xint" was used. I usually don't ascribe much value to micro benchmarks run in interpreter only mode, but hey any shaving off startup time is welcome. Less allocation is definitely welcome (although i do wish C2 was better at eliding redundant array initialization and allocation). - Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/449
Re: RFR: 8156071: List.of: reduce array copying during creation
On Thu, 1 Oct 2020 06:26:39 GMT, Martin Grigorov
wrote:
>> Plumb new internal static factory method to trust the array passed in,
>> avoiding unnecessary copying. JMH results for
>> the benchmark show about 15% improvement for the cases that were optimized,
>> namely the 3 to 10 fixed arg cases.
>> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview
>> -verbose:gc -XX:+UsePara
>> llelGC -Xms4g -Xmx4g -Xint
>> # Warmup: 5 iterations, 1 s each
>> # Measurement: 5 iterations, 2 s each
>>
>> WITHOUT varargs optimization:
>>
>> Benchmark Mode Cnt Score Error Units
>> ListArgs.list00 thrpt 15 6019.539 ± 144.040 ops/ms
>> ListArgs.list01 thrpt 15 1985.009 ± 40.606 ops/ms
>> ListArgs.list02 thrpt 15 1854.812 ± 17.488 ops/ms
>> ListArgs.list03 thrpt 15 963.866 ± 10.262 ops/ms
>> ListArgs.list04 thrpt 15 908.116 ± 6.278 ops/ms
>> ListArgs.list05 thrpt 15 848.607 ± 16.701 ops/ms
>> ListArgs.list06 thrpt 15 822.282 ± 8.905 ops/ms
>> ListArgs.list07 thrpt 15 780.057 ± 11.214 ops/ms
>> ListArgs.list08 thrpt 15 745.295 ± 19.204 ops/ms
>> ListArgs.list09 thrpt 15 704.596 ± 14.003 ops/ms
>> ListArgs.list10 thrpt 15 696.436 ± 4.914 ops/ms
>> ListArgs.list11 thrpt 15 661.908 ± 11.041 ops/ms
>>
>> WITH varargs optimization:
>>
>> Benchmark Mode Cnt ScoreError Units
>> ListArgs.list00 thrpt 15 6172.298 ± 62.736 ops/ms
>> ListArgs.list01 thrpt 15 1987.724 ± 45.468 ops/ms
>> ListArgs.list02 thrpt 15 1843.419 ± 10.693 ops/ms
>> ListArgs.list03 thrpt 15 1126.946 ± 30.952 ops/ms
>> ListArgs.list04 thrpt 15 1050.440 ± 17.859 ops/ms
>> ListArgs.list05 thrpt 15 999.275 ± 23.656 ops/ms
>> ListArgs.list06 thrpt 15 948.844 ± 19.615 ops/ms
>> ListArgs.list07 thrpt 15 897.541 ± 15.531 ops/ms
>> ListArgs.list08 thrpt 15 853.359 ± 18.755 ops/ms
>> ListArgs.list09 thrpt 15 826.394 ± 8.284 ops/ms
>> ListArgs.list10 thrpt 15 779.231 ± 4.104 ops/ms
>> ListArgs.list11 thrpt 15 650.888 ± 3.948 ops/ms
>
> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 88:
>
>> 86: if (javaUtilCollectionAccess == null) {
>> 87: try {
>> 88: Class.forName("java.util.ImmutableCollections$Access",
>> true, null);
>
> How does this work ? It attempts to load this class but
> `javaUtilCollectionAccess` is never assigned to a new value.
>
> **Update**: I just noticed this is the getter.
Yeah the SharedSecrets stuff is pretty twisted
-
PR: https://git.openjdk.java.net/jdk/pull/449
Re: RFR: 8156071: List.of: reduce array copying during creation
On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks wrote: > Plumb new internal static factory method to trust the array passed in, > avoiding unnecessary copying. JMH results for > the benchmark show about 15% improvement for the cases that were optimized, > namely the 3 to 10 fixed arg cases. > # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview > -verbose:gc -XX:+UsePara > llelGC -Xms4g -Xmx4g -Xint > # Warmup: 5 iterations, 1 s each > # Measurement: 5 iterations, 2 s each > > WITHOUT varargs optimization: > > Benchmark Mode Cnt Score Error Units > ListArgs.list00 thrpt 15 6019.539 ± 144.040 ops/ms > ListArgs.list01 thrpt 15 1985.009 ± 40.606 ops/ms > ListArgs.list02 thrpt 15 1854.812 ± 17.488 ops/ms > ListArgs.list03 thrpt 15 963.866 ± 10.262 ops/ms > ListArgs.list04 thrpt 15 908.116 ± 6.278 ops/ms > ListArgs.list05 thrpt 15 848.607 ± 16.701 ops/ms > ListArgs.list06 thrpt 15 822.282 ± 8.905 ops/ms > ListArgs.list07 thrpt 15 780.057 ± 11.214 ops/ms > ListArgs.list08 thrpt 15 745.295 ± 19.204 ops/ms > ListArgs.list09 thrpt 15 704.596 ± 14.003 ops/ms > ListArgs.list10 thrpt 15 696.436 ± 4.914 ops/ms > ListArgs.list11 thrpt 15 661.908 ± 11.041 ops/ms > > WITH varargs optimization: > > Benchmark Mode Cnt ScoreError Units > ListArgs.list00 thrpt 15 6172.298 ± 62.736 ops/ms > ListArgs.list01 thrpt 15 1987.724 ± 45.468 ops/ms > ListArgs.list02 thrpt 15 1843.419 ± 10.693 ops/ms > ListArgs.list03 thrpt 15 1126.946 ± 30.952 ops/ms > ListArgs.list04 thrpt 15 1050.440 ± 17.859 ops/ms > ListArgs.list05 thrpt 15 999.275 ± 23.656 ops/ms > ListArgs.list06 thrpt 15 948.844 ± 19.615 ops/ms > ListArgs.list07 thrpt 15 897.541 ± 15.531 ops/ms > ListArgs.list08 thrpt 15 853.359 ± 18.755 ops/ms > ListArgs.list09 thrpt 15 826.394 ± 8.284 ops/ms > ListArgs.list10 thrpt 15 779.231 ± 4.104 ops/ms > ListArgs.list11 thrpt 15 650.888 ± 3.948 ops/ms After a hint from @cl4es I ran the benchmarks with `-prof gc`. The allocation rate is reduced by about 40% per operation in the cases where the optimization was applied. WITHOUT varargs optimization: ListArgs.list00:·gc.alloc.rate.norm thrpt5≈ 10⁻⁴ B/op ListArgs.list01:·gc.alloc.rate.norm thrpt524.000 ±0.001 B/op ListArgs.list02:·gc.alloc.rate.norm thrpt524.000 ±0.001 B/op ListArgs.list03:·gc.alloc.rate.norm thrpt580.000 ±0.001 B/op ListArgs.list04:·gc.alloc.rate.norm thrpt580.036 ±0.309 B/op ListArgs.list05:·gc.alloc.rate.norm thrpt596.037 ±0.316 B/op ListArgs.list06:·gc.alloc.rate.norm thrpt596.038 ±0.326 B/op ListArgs.list07:·gc.alloc.rate.norm thrpt5 112.042 ±0.361 B/op ListArgs.list08:·gc.alloc.rate.norm thrpt5 112.043 ±0.367 B/op ListArgs.list09:·gc.alloc.rate.norm thrpt5 128.045 ±0.385 B/op ListArgs.list10:·gc.alloc.rate.norm thrpt5 128.046 ±0.391 B/op ListArgs.list11:·gc.alloc.rate.norm thrpt5 144.047 ±0.406 B/op WITH varargs optimization: ListArgs.list00:·gc.alloc.rate.norm thrpt5≈ 10⁻⁴ B/op ListArgs.list01:·gc.alloc.rate.norm thrpt524.000 ±0.001 B/op ListArgs.list02:·gc.alloc.rate.norm thrpt524.000 ±0.001 B/op ListArgs.list03:·gc.alloc.rate.norm thrpt548.000 ±0.001 B/op ListArgs.list04:·gc.alloc.rate.norm thrpt548.000 ±0.001 B/op ListArgs.list05:·gc.alloc.rate.norm thrpt556.000 ±0.001 B/op ListArgs.list06:·gc.alloc.rate.norm thrpt556.000 ±0.001 B/op ListArgs.list07:·gc.alloc.rate.norm thrpt564.000 ±0.001 B/op ListArgs.list08:·gc.alloc.rate.norm thrpt564.000 ±0.001 B/op ListArgs.list09:·gc.alloc.rate.norm thrpt572.000 ±0.001 B/op ListArgs.list10:·gc.alloc.rate.norm thrpt572.000 ±0.001 B/op ListArgs.list11:·gc.alloc.rate.norm thrpt5 144.050 ±0.427 B/op - PR: https://git.openjdk.java.net/jdk/pull/449
Re: RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
On Fri, 2 Oct 2020 18:44:48 GMT, Sean Mullan wrote:
>> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
>> Please also review the CSR at
>> https://bugs.openjdk.java.net/browse/JDK-8228481.
>
> test/jdk/sun/security/mscapi/VeryLongAlias.java line 51:
>
>> 49: public static void main(String[] args) throws Throwable {
>> 50:
>> 51: // Using the old algorithms to make sure the file is recognized
>
> Do we also want to have a test that uses the new algorithms?
I only know Windows Server 2019 can accept the new algorithms.
> test/lib/jdk/test/lib/security/DerUtils.java line 1:
>
>> 1: /*
>
> Is this test change supposed to be a part of this fix?
Yes, the change simplifies `checkAlg` calls so they don't need to convert
`KnownOIDs` or `String` to `ObjectIdentifier`
first.
-
PR: https://git.openjdk.java.net/jdk/pull/473
Re: RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote: > Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256. > Please also review the CSR at > https://bugs.openjdk.java.net/browse/JDK-8228481. test/lib/jdk/test/lib/security/DerUtils.java line 1: > 1: /* Is this test change supposed to be a part of this fix? - PR: https://git.openjdk.java.net/jdk/pull/473
Re: RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote:
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
test/jdk/sun/security/mscapi/VeryLongAlias.java line 51:
> 49: public static void main(String[] args) throws Throwable {
> 50:
> 51: // Using the old algorithms to make sure the file is recognized
Do we also want to have a test that uses the new algorithms?
-
PR: https://git.openjdk.java.net/jdk/pull/473
Integrated: 8239105 : Add exception for expiring Digicert root certificates to VerifyCACerts test
On Fri, 2 Oct 2020 16:21:47 GMT, Rajan Halade wrote: > 8239105 : Add exception for expiring Digicert root certificates to > VerifyCACerts test This pull request has now been integrated. Changeset: 123e786d Author:Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/123e786d Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test "8239105: added verisigntsaca and thawtepremiumserverca to EXPIRY_EXC_ENTRIES list" Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/484
Re: RFR: 8239105 : Add exception for expiring Digicert root certificates to VerifyCACerts test
On Fri, 2 Oct 2020 17:09:37 GMT, Sean Mullan wrote: > Looks good. Shouldn't we be seeing mach5 test failures from this though? I > didn't see any failures. We are still not beyond 90 days. It will start failing over the weekend. - PR: https://git.openjdk.java.net/jdk/pull/484
Re: RFR: 8239105 : Add exception for expiring Digicert root certificates to VerifyCACerts test
On Fri, 2 Oct 2020 16:21:47 GMT, Rajan Halade wrote: > 8239105 : Add exception for expiring Digicert root certificates to > VerifyCACerts test Looks good. Shouldn't we be seeing mach5 test failures from this though? I didn't see any failures. - Marked as reviewed by mullan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/484
RFR: 8239105: Add exception for expiring Digicert root certificates to Ver…
8239105: Add exception for expiring Digicert root certificates to Ver… - Commit messages: - 8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test Changes: https://git.openjdk.java.net/jdk/pull/484/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=484&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239105 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/484.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/484/head:pull/484 PR: https://git.openjdk.java.net/jdk/pull/484
RFR: 8251989: Hex formatting and parsing utility
java.util.HexFormat utility: - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase - Static factories and builder methods to create HexFormat copies with modified parameters. - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits... - Prefix and suffixes now apply to each formatted value, not the string as a whole - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions) - Immutable and thread safe, a "value-based" class See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details. Review comments and suggestions welcome. - Commit messages: - 8251989: Hex formatting and parsing utility Changes: https://git.openjdk.java.net/jdk/pull/482/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251989 Stats: 1665 lines in 12 files changed: 1503 ins; 144 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/482.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482 PR: https://git.openjdk.java.net/jdk/pull/482
