On Mon, 9 Oct 2023 04:58:10 GMT, Smita Kamath wrote:
>> Hi All,
>> I would like to submit AES-GCM optimization for x86_64 architectures using
>> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>>
>> Below are the performance numbers on my desktop system with -XX:UseA
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote:
> A few classes in `com.sun.crypto.provider` package have non-final fields
> which could easily be marked `final`.
src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line
109:
> 107: int tagLenBytes = DEFAULT
On Mon, 9 Oct 2023 16:36:06 GMT, Kevin Driver wrote:
> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
> initializing the HashSet with a more accurate number
This pull request has now been integrated.
Changeset: e882718a
Author:Kevin Driver
URL:
https://git.open
> Hi All,
> I would like to submit AES-GCM optimization for x86_64 architectures using
> AVX2 instructions. This optimization interleaves AES and GHASH operations.
>
> Below are the performance numbers on my desktop system with -XX:UseAVX=2
> option:
>
> |Benchmark | Data Size | Base version (
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote:
> A few classes in `com.sun.crypto.provider` package have non-final fields
> which could easily be marked `final`.
src/java.base/share/classes/com/sun/crypto/provider/EncryptedPrivateKeyInfo.java
line 1:
> 1: /*
Hmm, there is also sun/
On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less acceptin
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote:
> A few classes in `com.sun.crypto.provider` package have non-final fields
> which could easily be marked `final`.
src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 276:
> 274: }
> 275:
> 276: private vo
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote:
> A few classes in `com.sun.crypto.provider` package have non-final fields
> which could easily be marked `final`.
src/java.base/share/classes/com/sun/crypto/provider/DHPrivateKey.java line 61:
> 59:
> 60: // the key bytes, without
On Thu, 24 Aug 2023 08:53:53 GMT, Andrey Turbanov wrote:
> A few classes in `com.sun.crypto.provider` package have non-final fields
> which could easily be marked `final`.
I'll take a look.
-
PR Comment: https://git.openjdk.org/jdk/pull/15412#issuecomment-1753872702
> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
> initializing the HashSet with a more accurate number
Kevin Driver has updated the pull request incrementally with one additional
commit since the last revision:
specify type for HashSet
-
Changes:
- all: h
On Mon, 9 Oct 2023 20:44:50 GMT, Kevin Driver wrote:
>> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
>> initializing the HashSet with a more accurate number
>
> Kevin Driver has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
> initializing the HashSet with a more accurate number
Kevin Driver has updated the pull request incrementally with one additional
commit since the last revision:
convert Set back to HashSet
-
Changes:
- all
> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
> initializing the HashSet with a more accurate number
Kevin Driver has updated the pull request incrementally with one additional
commit since the last revision:
use a Set per code review comments
-
Changes:
On Mon, 9 Oct 2023 20:13:48 GMT, Jamil Nimeh wrote:
>> Do you think we'll lose performance in a meaningful way? One of the
>> guarantees of HashSet is constant-time operations.
>>
>> There is no such guarantee for Set. The number of members is probably small
>> enough, relatively speaking, to
On Mon, 9 Oct 2023 19:19:49 GMT, Kevin Driver wrote:
>> I wondered about an approach like this. I'll push another commit with these
>> changes.
>
> Do you think we'll lose performance in a meaningful way? One of the
> guarantees of HashSet is constant-time operations.
>
> There is no such gua
On Mon, 9 Oct 2023 18:59:43 GMT, Kevin Driver wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line
>> 59:
>>
>>> 57:
>>> 58: static {
>>> 59: validTypes = HashSet.newHashSet(21);
>>
>> Rather than having to change the initial size and keep it synch
On Mon, 9 Oct 2023 17:00:45 GMT, Jamil Nimeh wrote:
>> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
>> initializing the HashSet with a more accurate number
>
> src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line
> 59:
>
>> 57:
>> 58: static {
> Limit native memory allocation and move write loop from the native layer into
> Java. This change should make the OOME reported in the issue much less likely.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the un
On Mon, 9 Oct 2023 16:36:06 GMT, Kevin Driver wrote:
> fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
> initializing the HashSet with a more accurate number
src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java line 59:
> 57:
> 58: static {
> 59:
fixes [JDK-8314199](https://bugs.openjdk.org/browse/JDK-8314199) by
initializing the HashSet with a more accurate number
-
Commit messages:
- fixes JDK-8314199 by initializing the HashSet with a more accurate number
Changes: https://git.openjdk.org/jdk/pull/16103/files
Webrev: htt
20 matches
Mail list logo
