> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>
> The problem is each instance of GHASH allocates 96 extra longs for the
> AVX51
On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino
wrote:
>> Smita Kamath has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain
>> and added a new constant for htbl e
On Tue, 21 Sep 2021 17:52:31 GMT, Brian Burkhalter wrote:
>> We can either revert this part of the change or rephrase it. Mind you,
>> rephrasing might prove tricky because of non-local changes it might
>> introduce. There's one more occurrence of "wrapped exception" in this file:
>> https://g
On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino
wrote:
>> Smita Kamath has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain
>> and added a new constant for htbl e
I'll run them.. Did you seem my comments? They are just code-style comments
thanks
Tony
On 9/21/21 12:43 PM, Smita Kamath wrote:
On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino
wrote:
Smita Kamath has updated the pull request incrementally with one additional
commit since the last rev
On Mon, 20 Sep 2021 16:44:58 GMT, Anthony Scarpino
wrote:
>> Smita Kamath has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain
>> and added a new constant for htbl e
On Tue, 21 Sep 2021 18:31:12 GMT, Smita Kamath wrote:
>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
>> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
>> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>>
>> The problem is eac
On Tue, 21 Sep 2021 16:37:49 GMT, Sandhya Viswanathan
wrote:
>> Smita Kamath has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a wrapper around aes-gcm intrinsic, changed data size in TestAESMain
>> and added a new constant for htb
> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>
> The problem is each instance of GHASH allocates 96 extra longs for the
> AVX51
On Tue, 21 Sep 2021 17:39:41 GMT, Pavel Rappo wrote:
>> Would "wrappER" be better?
>
> We can either revert this part of the change or rephrase it. Mind you,
> rephrasing might prove tricky because of non-local changes it might
> introduce. There's one more occurrence of "wrapped exception" in
On Tue, 21 Sep 2021 17:14:31 GMT, Pavel Rappo wrote:
>> Subjectively, "wrapping exception" would seem to be an exception in the
>> process of wrapping something.
>
> Would "wrappER" be better?
We can either revert this part of the change or rephrase it. Mind you,
rephrasing might prove tricky
On Tue, 21 Sep 2021 17:10:02 GMT, Brian Burkhalter wrote:
>> If we have two exceptions A and B, such that B is the cause of A, then A is
>> the wrapping exception (the one that wraps or the wrapper) and B is the
>> wrapped exception (the one that is being wrapped or the wrappee).
>>
>> I notic
On Tue, 21 Sep 2021 16:56:03 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/lang/Throwable.java line 68:
>>
>>> 66: * Further, doing so would tie the API of the upper layer to the
>>> details of
>>> 67: * its implementation, assuming the lower layer's exception was a
>>> chec
On Tue, 21 Sep 2021 17:07:45 GMT, Pavel Rappo wrote:
>> It does seem a bit strange to say "Throwing a wrapping"
>
> If we have two exceptions A and B, such that B is the cause of A, then A is
> the wrapping exception (the one that wraps or the wrapper) and B is the
> wrapped exception (the
On Tue, 21 Sep 2021 16:48:53 GMT, Brian Burkhalter wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Tweak wording for Throwable constructor parameters
>
> src/java.base/share/classes/java/lang/Throwable.java line 68:
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
Overall looks like a g
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
src/java.base/share/cl
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
Marked as reviewed by
On Mon, 20 Sep 2021 05:16:16 GMT, Smita Kamath wrote:
>> Performance dropped up to 10% for 1k data after 8267125 for CPUs that do not
>> support the new intrinsic. Tests run were crypto.full.AESGCMBench and
>> crypto.full.AESGCMByteBuffer from the jmh micro benchmarks.
>>
>> The problem is eac
On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo wrote:
>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Tweak wording for Throwable constructor parameters
Marked as reviewed by
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov
wrote:
> Pass "cause" exception as constructor parameter is shorter and easier to read.
Looks fine. Thanks.
-
Marked as reviewed by weijun (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5551
On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov
wrote:
> Pass "cause" exception as constructor parameter is shorter and easier to read.
This will need to be thoroughly tested to make sure there were no implicit
dependencies on now-removed happens-before edges (`initCause` is synchronized).
On Tue, 31 Aug 2021 18:53:36 GMT, Sean Mullan wrote:
> This change will disable JARs signed with algorithms using SHA-1 by default,
> and treat them as unsigned. This applies to the algorithms used to digest,
> sign, and optionally timestamp the JAR. It also applies to the signature and
> dige
Pass "cause" exception as constructor parameter is shorter and easier to read.
-
Commit messages:
- [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.base
module
Changes: https://git.openjdk.java.net/jdk/pull/5551/files
Webrev: https://webrevs.openjdk.java.net/?re
> 8274075: Fix miscellaneous typos in java.base
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Tweak wording for Throwable constructor parameters
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5610/files
- n
On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo wrote:
> 8274075: Fix miscellaneous typos in java.base
Marked as reviewed by dfuchs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5610
8274075: Fix miscellaneous typos in java.base
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jdk/pull/5610/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5610&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8274075
Stats: 21 line
On Wed, 15 Sep 2021 08:01:30 GMT, Thejasvi Voniadka
wrote:
> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs
> interoperability checks between JDK and openssl with respect to certain
> keystore operations. The test requires a suitable version of openssl to be
> availabl
On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long) as
> The test "sun/security/pkcs12/KeytoolOpensslInteropTest.java" performs
> interoperability checks between JDK and openssl with respect to certain
> keystore operations. The test requires a suitable version of openssl to be
> available on the machine it runs. Some mechanisms are used to discover
On Wed, 8 Sep 2021 02:10:36 GMT, David Schlosnagle
wrote:
>> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed
>> a few places, where Vector could be replaced with ArrayList.
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `Array
On Thu, 26 Aug 2021 06:19:49 GMT, Andrey Turbanov
wrote:
> In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a
> few places, where Vector could be replaced with ArrayList.
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList`
In [JDK-8268873](https://bugs.openjdk.java.net/browse/JDK-8268873) I missed a
few places, where Vector could be replaced with ArrayList.
Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
use `ArrayList` if a thread-safe implementation is not needed.
-
Comm
33 matches
Mail list logo
