Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. The changes looks good. I am assuming that we do not need an additional test for this and if so, please add a noreg label such as noreg-trivial to the bug - PR: https://git.openjdk.java.net/jdk/pull/1299
Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. This seems like a good optimization. I think comparing the manifest name case insensitively might be preferable - e.g. using String.equalsIgnoreCase - but if the worst that can happen is that a non-conventionally cased is read twice then I think what you have here is good. - Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1299
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
An honest question, why do we need so many interfaces for the different categories of RandomGenerator ? My fear is that we are encoding the state of our knowledge of the different kinds of random generators now so it will not be pretty in the future when new categories of random generator are discovered/invented. If we can take example of the past to predict the future, 20 years ago, what should have been the hierarchy at that time. Is it not reasonable to think that we will need new kinds of random generator in the future ? I wonder if it's not better to have one interface and several optional methods like we have with the collections, it means that we are loosing the possibilities to precisely type a method that only works with a precise type of generator but it will be more future proof. Rémi - Mail original - > De: "Jim Laskey" > À: "build-dev" , "core-libs-dev" > , > security-dev@openjdk.java.net > Envoyé: Mardi 17 Novembre 2020 23:21:18 > Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators > [v3] >> This PR is to introduce a new random number API for the JDK. The primary API >> is >> found in RandomGenerator and RandomGeneratorFactory. Further description can >> be >> found in the JEP https://openjdk.java.net/jeps/356 . > > Jim Laskey has updated the pull request with a new target base due to a merge > or > a rebase. The pull request now contains 40 commits: > > - Merge branch 'master' into 8248862 > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Update package-info.java > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Updated RandomGeneratorFactory javadoc. > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Updated documentation for RandomGeneratorFactory. > - Merge branch 'master' into 8248862 > - Merge branch 'master' into 8248862 > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Move RandomGeneratorProperty > - Merge branch 'master' into 8248862 > - 8248862: Implement Enhanced Pseudo-Random Number Generators > > Clear up javadoc > - 8248862; Implement Enhanced Pseudo-Random Number Generators > > remove RandomGeneratorProperty from API > - ... and 30 more: > https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68 > > - > > Changes: https://git.openjdk.java.net/jdk/pull/1273/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1273=02 > Stats: 14891 lines in 31 files changed: 0 ins; 3704 del; 77 mod > Patch: https://git.openjdk.java.net/jdk/pull/1273.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273 > > PR: https://git.openjdk.java.net/jdk/pull/1273
RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR
Small change to retrieve the raw bytes of manifest during verifying signed JAR. - Commit messages: - 8253299: Manifest bytes are read twice when verifying a signed JAR Changes: https://git.openjdk.java.net/jdk/pull/1299/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1299=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253299 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1299.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1299/head:pull/1299 PR: https://git.openjdk.java.net/jdk/pull/1299
Re: RFR: 8256523: Streamline Java SHA2 implementation
On Wed, 18 Nov 2020 08:29:49 GMT, Aleksey Shipilev wrote: > Current `sun/security/provider/SHA2` implementation is written with lots of > small method invocations on the fastpath in `implCompress0`. Normally it does > not matter much, because compilers are able to inline through it, and then > some compilers even intrinsify the entire `implCompress0`. > > But it comes as major downside for platforms that do not have SHA2 > intrinsics, or those VM configs that blindly interpret the bytecode. Zero, > for example, keeps re-entering the small methods when computing SHA2 digests > during jmod/jlink generation during the build, and spends significant time > there. Linux x86_64 Zero fastdebug builds **improve from 18.5 minutes to 11.0 > minutes** with this change, which is a major win for development experience. > > Note that SHA1 is already written in similar streamlined style. SHA5 is > written with helper functions. This patch moves SHA2 to be closer to SHA1 > style-wise. > > Performance improvement in interpreted modes is substantial, about 4x..5x, > while compiler modes are not affected. As measured by: `make test > TEST="micro:MessageDigests" > MICRO="FORK=1;ITER=5;WARMUP_ITER=5;WARMUP_TIME=1s;TIME=1s;OPTIONS=-p > digesterName=sha256 -p provider=SUN"` > > Before: > > Benchmark (digesterName) (length) (provider) Mode Cnt > Score ErrorUnits > > # Server, Default > MessageDigests.digest sha25664 SUN thrpt5 > 8585.532 ± 219.896 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 1545.994 ± 73.325 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 110.550 ± 1.576 ops/ms > > # Server, -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA256Intrinsics > MessageDigests.digest sha25664 SUN thrpt5 > 1426.117 ± 48.320 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 188.779 ± 0.097 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 12.512 ± 1.371 ops/ms > > # Server, -Xint > MessageDigests.digest sha25664 SUN thrpt5 > 6.143 ± 0.126 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 0.769 ± 0.008 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 0.051 ± 0.001 ops/ms > > # Zero > MessageDigests.digest sha25664 SUN thrpt5 > 5.358 ± 0.664 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 0.686 ± 0.003 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 0.046 ± 0.001 ops/ms > > After: > > Benchmark (digesterName) (length) (provider) Mode Cnt > Score Error Units > > # Server, Default > MessageDigests.digest sha25664 SUN thrpt5 > 8564.689 ± 1459.552 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 1548.582 ± 78.888 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 110.800 ±0.057 ops/ms > > # Server, -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA256Intrinsics > MessageDigests.digest sha25664 SUN thrpt5 > 1471.399 ± 66.622 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 186.297 ±0.127 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 12.448 ±0.099 ops/ms > > # Server, -Xint > MessageDigests.digest sha25664 SUN thrpt5 > 27.046 ±0.304 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 3.538 ±0.060 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 0.238 ±0.002 ops/ms > > # Zero > MessageDigests.digest sha25664 SUN thrpt5 > 26.696 ±0.968 ops/ms > MessageDigests.digest sha256 1024 SUN thrpt5 > 3.655 ±0.024 ops/ms > MessageDigests.digest sha256 16384 SUN thrpt5 > 0.241 ±0.002 ops/ms > > Addtional testing: > - [x] `jdk/security` with Linux x86_64 server fastdebug > - [x] `jdk/security` with Linux x86_64 zero fastdebug Sounds impressive, I will take a look. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/1283
Re: RFR: 8256507: Add a micro benchmark for JDK-8153005 [v2]
> This is a micro benchmark for various algorithm settings of PKCS keystores. > Strong for new algorithms and weak for old ones. Different iteration counts > are tried. The result should show that the current setting (strong1) is > more efficient than old setting (weak5). Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: not static anymore - Changes: - all: https://git.openjdk.java.net/jdk/pull/1277/files - new: https://git.openjdk.java.net/jdk/pull/1277/files/df96a06e..9247081d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1277=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1277=00-01 Stats: 67 lines in 1 file changed: 0 ins; 28 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/1277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1277/head:pull/1277 PR: https://git.openjdk.java.net/jdk/pull/1277
Re: RFR: 8256507: Add a micro benchmark for JDK-8153005 [v2]
On Wed, 18 Nov 2020 13:50:14 GMT, Aleksey Shipilev wrote: >> Weijun Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> not static anymore > > I think the benchmark can be simplified. New commit. No more static fields. Thanks. @shipilev. - PR: https://git.openjdk.java.net/jdk/pull/1277
Re: RFR: 8202343: Disable TLS 1.0 and 1.1 [v2]
On Wed, 18 Nov 2020 15:45:02 GMT, Sean Coffey wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> More test changes.
>
> test/lib/jdk/test/lib/security/SecurityUtils.java line 64:
>
>> 62: }
>> 63:
>> 64: private static void removeFromDisabledAlgs(String prop, List
>> algs) {
>
> Useful utility method. Maybe it can be made public/ opened up and renamed to
> something like "removeFromSecurityProperty" perhaps ? could be done at a
> later time perhaps.
Yes, that's the main reason why I put that code into a separate method, so that
we could consider adding more methods that call it or using it more generally
in subsequent fixes where we need to re-enable disabled algorithms.
-
PR: https://git.openjdk.java.net/jdk/pull/1235
Re: RFR: 8256507: Add a micro benchmark for JDK-8153005
On Wed, 18 Nov 2020 14:49:54 GMT, Weijun Wang wrote:
>> test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 65:
>>
>>> 63: }
>>> 64:
>>> 65: static {
>>
>> Move these to
>>
>> @Setup
>> public void setup() throws Exception {
>> ...
>> }
>>
>> This would save you a `try-catch` section, and harness would properly fail
>> on setup exception.
>
> Newbie on JMH. Is it worth designing the byte[] fields as static? I assume
> there will be different objects for different forks but only one for
> different threads?
It does not worth it to make fields `static`. It is much better to let JMH
manage the setup, that's what `@Setup` methods are for. If you want to share
all instance fields across the thread, then use `@State(Scope.Benchmark)`, it
is now `Scope.Thread`.
-
PR: https://git.openjdk.java.net/jdk/pull/1277
Re: RFR: 8202343: Disable TLS 1.0 and 1.1 [v2]
On Tue, 17 Nov 2020 17:55:19 GMT, Sean Mullan wrote:
>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the
>> jdk.tls.disabledAlgorithms security property in the java.security file.
>> These protocols use weak algorithms and are being deprecated by the IETF.
>> They should be disabled by default to improve the default security
>> configuration of the JDK. See the CSR for more rationale:
>> https://bugs.openjdk.java.net/browse/JDK-8254713
>>
>> The fix mostly involves changes to existing tests that for one reason or
>> another depend on the TLSv1 and TLSv1.1 protocols being enabled. There is a
>> new test specifically for this issue:
>> test/jdk/sun/security/ssl/SSLContextImpl/SSLContextDefault.java
>
> Sean Mullan has updated the pull request incrementally with one additional
> commit since the last revision:
>
> More test changes.
Marked as reviewed by coffeys (Reviewer).
test/lib/jdk/test/lib/security/SecurityUtils.java line 64:
> 62: }
> 63:
> 64: private static void removeFromDisabledAlgs(String prop, List
> algs) {
Useful utility method. Maybe it can be made public/ opened up and renamed to
something like "removeFromSecurityProperty" perhaps ? could be done at a later
time perhaps.
-
PR: https://git.openjdk.java.net/jdk/pull/1235
Re: RFR: 8256507: Add a micro benchmark for JDK-8153005
On Wed, 18 Nov 2020 13:46:04 GMT, Aleksey Shipilev wrote:
>> This is a micro benchmark for various algorithm settings of PKCS keystores.
>> Strong for new algorithms and weak for old ones. Different iteration counts
>> are tried. The result should show that the current setting (strong1) is
>> more efficient than old setting (weak5).
>
> test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 65:
>
>> 63: }
>> 64:
>> 65: static {
>
> Move these to
>
> @Setup
> public void setup() throws Exception {
> ...
> }
>
> This would save you a `try-catch` section, and harness would properly fail on
> setup exception.
Newbie on JMH. Is it worth designing the byte[] fields as static? I assume
there will be different objects for different forks but only one for different
threads?
> test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 137:
>
>> 135: "PBEWithSHA1AndDESede", "2048",
>> 136: "HmacPBESHA1", "2048");
>> 137: }
>
> Any reason why these methods are not inlined into `@Benchmark` methods right
> away? E.g. why it is not:
>
> @Benchmark
> public byte[] outweak2048() throws Exception {
> return out("PBEWithSHA1AndRC2_40", "2048",
> "PBEWithSHA1AndDESede", "2048",
> "HmacPBESHA1", "2048");
> }
I want to make the byte[] fields static so the out() and gen***() methods must
be static, and there is a warning on using a static method as a `@Benchmark`
method.
-
PR: https://git.openjdk.java.net/jdk/pull/1277
Re: RFR: 8256507: Add a micro benchmark for JDK-8153005
On Tue, 17 Nov 2020 21:46:38 GMT, Weijun Wang wrote:
> This is a micro benchmark for various algorithm settings of PKCS keystores.
> Strong for new algorithms and weak for old ones. Different iteration counts
> are tried. The result should show that the current setting (strong1) is
> more efficient than old setting (weak5).
I think the benchmark can be simplified.
test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 65:
> 63: }
> 64:
> 65: static {
Move these to
@Setup
public void setup() throws Exception {
...
}
This would save you a `try-catch` section, and harness would properly fail on
setup exception.
test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.java line 137:
> 135: "PBEWithSHA1AndDESede", "2048",
> 136: "HmacPBESHA1", "2048");
> 137: }
Any reason why these methods are not inlined into `@Benchmark` methods right
away? E.g. why it is not:
@Benchmark
public byte[] outweak2048() throws Exception {
return out("PBEWithSHA1AndRC2_40", "2048",
"PBEWithSHA1AndDESede", "2048",
"HmacPBESHA1", "2048");
}
-
Changes requested by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1277
RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 . javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html old PR: https://github.com/openjdk/jdk/pull/1273 - Commit messages: - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862; Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - 8248862: Implement Enhanced Pseudo-Random Number Generators - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7 Changes: https://git.openjdk.java.net/jdk/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1292=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248862 Stats: 13319 lines in 25 files changed: 0 ins; 2132 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/jdk/pull/1292
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey wrote: >> I am unsure if the intent is also to support external libraries providing >> `RandomGenerator` implementations. Currently there is an implicit contract >> for properties (reflectively invoking a method returning a map with a set of >> entries with known keys). Since the service provider implementation is the >> `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder >> expose the meta-data with a clearer contract. > > Need rebase Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292 - PR: https://git.openjdk.java.net/jdk/pull/1273
Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz wrote: >> Jim Laskey has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 40 commits: >> >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Update package-info.java >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated RandomGeneratorFactory javadoc. >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Updated documentation for RandomGeneratorFactory. >> - Merge branch 'master' into 8248862 >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Move RandomGeneratorProperty >> - Merge branch 'master' into 8248862 >> - 8248862: Implement Enhanced Pseudo-Random Number Generators >> >>Clear up javadoc >> - 8248862; Implement Enhanced Pseudo-Random Number Generators >> >>remove RandomGeneratorProperty from API >> - ... and 30 more: >> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68 > > I am unsure if the intent is also to support external libraries providing > `RandomGenerator` implementations. Currently there is an implicit contract > for properties (reflectively invoking a method returning a map with a set of > entries with known keys). Since the service provider implementation is the > `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder > expose the meta-data with a clearer contract. Need rebase - PR: https://git.openjdk.java.net/jdk/pull/1273
Withdrawn: 8248862: Implement Enhanced Pseudo-Random Number Generators
On Tue, 17 Nov 2020 19:58:47 GMT, Jim Laskey wrote: > This PR is to introduce a new random number API for the JDK. The primary API > is found in RandomGenerator and RandomGeneratorFactory. Further description > can be found in the JEP https://openjdk.java.net/jeps/356 . This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jdk/pull/1273
Integrated: 8256363: Define toString() for MGF1ParameterSpec
On Fri, 13 Nov 2020 21:13:54 GMT, Weijun Wang wrote: > Without this method, `PSSParameterSpec::toString` shows something like: > MD: SHA-256 > MGF: java.security.spec.MGF1ParameterSpec@77b52d12 > SaltLength: 32 > TrailerField: 1 > This is ugly. > > Noreg-trivial. This pull request has now been integrated. Changeset: 486d6f63 Author:Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/486d6f63 Stats: 17 lines in 3 files changed: 6 ins; 2 del; 9 mod 8256363: Define toString() for MGF1ParameterSpec Reviewed-by: mullan - PR: https://git.openjdk.java.net/jdk/pull/1208
Re: RFR: 8256363: Define toString() for MGF1ParameterSpec [v3]
On Tue, 17 Nov 2020 15:37:18 GMT, Weijun Wang wrote: >> Without this method, `PSSParameterSpec::toString` shows something like: >> MD: SHA-256 >> MGF: java.security.spec.MGF1ParameterSpec@77b52d12 >> SaltLength: 32 >> TrailerField: 1 >> This is ugly. >> >> Noreg-trivial. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision: > > choose a record-style format Marked as reviewed by mullan (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1208
RFR: 8256523: Streamline Java SHA2 implementation
Current `sun/security/provider/SHA2` implementation is written with lots of small method invocations on the fastpath in `implCompress0`. Normally it does not matter much, because compilers are able to inline through it, and then some compilers even intrinsify the entire `implCompress0`. But it comes as major downside for platforms that do not have SHA2 intrinsics, or those VM configs that blindly interpret the bytecode. Zero, for example, keeps re-entering the small methods when computing SHA2 digests during jmod/jlink generation during the build, and spends significant time there. Linux x86_64 Zero fastdebug builds **improve from 18.5 minutes to 11.0 minutes** with this change, which is a major win for development experience. Note that SHA1 is already written in similar streamlined style. SHA5 is written with helper functions. This patch moves SHA2 to be closer to SHA1 style-wise. Performance improvement in interpreted modes is substantial, about 4x..5x, while compiler modes are not affected. As measured by: `make test TEST="micro:MessageDigests" MICRO="FORK=1;ITER=5;WARMUP_ITER=5;WARMUP_TIME=1s;TIME=1s;OPTIONS=-p digesterName=sha256 -p provider=SUN"` Before: Benchmark (digesterName) (length) (provider) Mode Cnt Score ErrorUnits # Server, Default MessageDigests.digest sha25664 SUN thrpt5 8585.532 ± 219.896 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 1545.994 ± 73.325 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 110.550 ± 1.576 ops/ms # Server, -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA256Intrinsics MessageDigests.digest sha25664 SUN thrpt5 1426.117 ± 48.320 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 188.779 ± 0.097 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 12.512 ± 1.371 ops/ms # Server, -Xint MessageDigests.digest sha25664 SUN thrpt5 6.143 ± 0.126 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 0.769 ± 0.008 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 0.051 ± 0.001 ops/ms # Zero MessageDigests.digest sha25664 SUN thrpt5 5.358 ± 0.664 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 0.686 ± 0.003 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 0.046 ± 0.001 ops/ms After: Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units # Server, Default MessageDigests.digest sha25664 SUN thrpt5 8564.689 ± 1459.552 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 1548.582 ± 78.888 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 110.800 ±0.057 ops/ms # Server, -XX:+UnlockDiagnosticVMOptions -XX:-UseSHA256Intrinsics MessageDigests.digest sha25664 SUN thrpt5 1471.399 ± 66.622 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 186.297 ±0.127 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 12.448 ±0.099 ops/ms # Server, -Xint MessageDigests.digest sha25664 SUN thrpt5 27.046 ±0.304 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 3.538 ±0.060 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 0.238 ±0.002 ops/ms # Zero MessageDigests.digest sha25664 SUN thrpt5 26.696 ±0.968 ops/ms MessageDigests.digest sha256 1024 SUN thrpt5 3.655 ±0.024 ops/ms MessageDigests.digest sha256 16384 SUN thrpt5 0.241 ±0.002 ops/ms Addtional testing: - [x] `jdk/security` with Linux x86_64 server fastdebug - [x] `jdk/security` with Linux x86_64 zero fastdebug - Commit messages: - 8256523: Streamline Java SHA2 implementation Changes: https://git.openjdk.java.net/jdk/pull/1283/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1283=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256523 Stats: 123 lines in 1 file changed: 41 ins; 78 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1283/head:pull/1283 PR: https://git.openjdk.java.net/jdk/pull/1283
