Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Daniel Fuchs
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread 江莎
+ security-dev Hi Peter, It looks both of file 1 and 5 contain that close_notify warning alert. This point may be related to JDK-8208526: TLS 1.3 half-close and synchronization issues [1]. [1] https://bugs.openjdk.java.net/browse/JDK-8208526 Best regards, John Jiang At 2021/8/11 PM 4:14, Peter

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread Peter Firmstone
谢谢johnsjiang(江莎), I set the property: -Djdk.tls.acknowledgeCloseNotify=true. Unfortunately the test is still failing on JDK17, although the output has changed and acknowledges the duplex close, so it appears something else is causing the connection to close early. Interestingly, there is a W

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v8]

2021-08-11 Thread Andrew Haley
On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures >> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES >> and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. >

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v8]

2021-08-11 Thread Andrew Haley
On Mon, 9 Aug 2021 15:49:07 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures >> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES >> and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above. >

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Naoto Sato
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v9]

2021-08-11 Thread Smita Kamath
> I would like to submit AES-GCM optimization for x86_64 architectures > supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES > and GHASH operations. > Performance gain of ~1.5x - 2x for message sizes 8k and above. Smita Kamath has updated the pull request incrementally wit

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Alan Bateman
On Tue, 10 Aug 2021 18:41:04 GMT, Claes Redestad wrote: > Yes, while I don't know exactly which changes resolved JDK-6764325, it's > clear from the microbenchmarks added for #2102 that it's no longer an issue - > at least not in the mainline. Thanks for checking and for closing that issue. --

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Alan Bateman
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Daniel Fuchs
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Naoto Sato
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U

Re: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions [v9]

2021-08-11 Thread Valerie Peng
On Wed, 11 Aug 2021 17:49:57 GMT, Smita Kamath wrote: >> I would like to submit AES-GCM optimization for x86_64 architectures >> supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES >> and GHASH operations. >> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Re: JDK17 - Possible TLS issue.

2021-08-11 Thread Peter Firmstone
Thanks Jamil, You'll need to use JDK 8 for building / compiling, Additional to the build instructions, to test the specific test in question: Create a build.properties file in the project root directory (same directory as README.md), containing the following entries: jsk.home=absolute pat

Integrated: 8272120: Avoid looking for standard encodings in "java." modules

2021-08-11 Thread Sergey Bylokhov
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote: > This is the continuation of JDK-8233884 and JDK-8271456. This change affects > fewer cases so I fix all "java." modules at once. > > In many places standard charsets are looked up via their names, for example: > absolutePath.getBytes("U