Re: RFR: 8247645: ChaCha20 intrinsics [v4]

2022-11-21 Thread Jamil Nimeh
On Mon, 21 Nov 2022 19:06:49 GMT, Vladimir Ivanov wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Pull out common macro code into function parameter pack > > src/hotspot/cpu/x86/stubGenerator_x86_64_chacha.cpp line

Re: RFR: 8247645: ChaCha20 intrinsics [v5]

2022-11-21 Thread Jamil Nimeh
> This PR delivers ChaCha20 intrinsics that accelerate the core block function > that generates key stream from the key, counter and nonce. Intrinsics have > been written for the following platforms and instruction sets: > > - x86_64: AVX, AVX2 and AVX512 > - aarch64: platforms that support the

Integrated: 8297301: Cleanup unused methods in JavaUtilJarAccess

2022-11-21 Thread pandaapo
On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo wrote: > The cache named `signerToCodeSource` in `JarVerifier` is never used now. This pull request has now been integrated. Changeset: f0e99c63 Author:pandaapo <1052156...@qq.com> Committer: Weijun Wang URL: https://git.openjdk.org/jdk/com

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]

2022-11-21 Thread pandaapo
On Tue, 22 Nov 2022 01:44:29 GMT, Weijun Wang wrote: > Everything looks fine now. Thanks so much for the cleanup. It's always nice > to see unused lines removed. Thank you for your review. - PR: https://git.openjdk.org/jdk/pull/11072

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]

2022-11-21 Thread Weijun Wang
On Tue, 22 Nov 2022 00:45:00 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional > commit since the last revision: > > Modify as reviews. Everything looks fine now. Thanks

Re: RFR: 8247645: ChaCha20 intrinsics [v4]

2022-11-21 Thread Vladimir Ivanov
On Mon, 21 Nov 2022 06:28:32 GMT, Jamil Nimeh wrote: >> This PR delivers ChaCha20 intrinsics that accelerate the core block function >> that generates key stream from the key, counter and nonce. Intrinsics have >> been written for the following platforms and instruction sets: >> >> - x86_64:

Re: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v22]

2022-11-21 Thread David Holmes
On Thu, 17 Nov 2022 20:42:27 GMT, Volodymyr Paprotski wrote: >> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 >> message blocks at a time. For more details, left a lot of comments in >> `macroAssembler_x86_poly.cpp`. >> >> - Added new KAT test for Poly1305 and a fuzz

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7]

2022-11-21 Thread pandaapo
> The cache named `signerToCodeSource` in `JarVerifier` is never used now. pandaapo has updated the pull request incrementally with one additional commit since the last revision: Modify as reviews. - Changes: - all: https://git.openjdk.org/jdk/pull/11072/files - new: https://

Integrated: JDK-8297164: Update troff man pages and CheckManPageOptions.java

2022-11-21 Thread Jonathan Gibbons
On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update > to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated,

Integrated: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions

2022-11-21 Thread Volodymyr Paprotski
On Wed, 5 Oct 2022 21:28:26 GMT, Volodymyr Paprotski wrote: > Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 > message blocks at a time. For more details, left a lot of comments in > `macroAssembler_x86_poly.cpp`. > > - Added new KAT test for Poly1305 and a fuzz test t

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore wrote: >>> Although this looks much simpler and concise, it means "a new object is >>> created for each invocation" >> >> My comment was actually to see if DirectBuffer could extend AutoCloseable so >> that the acquire returns "this" for

Re: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v22]

2022-11-21 Thread Vladimir Ivanov
On Thu, 17 Nov 2022 20:42:27 GMT, Volodymyr Paprotski wrote: >> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16 >> message blocks at a time. For more details, left a lot of comments in >> `macroAssembler_x86_poly.cpp`. >> >> - Added new KAT test for Poly1305 and a fuzz

Re: RFR: 8296507: GCM using more memory than necessary with in-place operations [v2]

2022-11-21 Thread Anthony Scarpino
On Fri, 18 Nov 2022 05:19:31 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java >> line 694: >> >>> 692: int originalOutOfs = 0; >>> 693: >>> 694: // True if op is in-place array decryption with the input & >>> output >>

Re: RFR: 8296507: GCM using more memory than necessary with in-place operations [v2]

2022-11-21 Thread Anthony Scarpino
On Wed, 16 Nov 2022 17:01:50 GMT, Mark Powers wrote: >> Anthony Scarpino has updated the pull request incrementally with one >> additional commit since the last revision: >> >> comment cleanup & finesse ByteBuffer implGCMCrypt better > > src/java.base/share/classes/com/sun/crypto/provider/Gal

Re: RFR: 8296507: GCM using more memory than necessary with in-place operations

2022-11-21 Thread Anthony Scarpino
On Sun, 13 Nov 2022 02:54:10 GMT, Anthony Scarpino wrote: > I would like a review of an update to the GCM code. A recent report showed > that GCM memory usage for TLS was very large. This was a result of in-place > buffers, which TLS uses, and how the code handled the combined intrinsic > m

Re: RFR: 8296507: GCM using more memory than necessary with in-place operations [v2]

2022-11-21 Thread Anthony Scarpino
> I would like a review of an update to the GCM code. A recent report showed > that GCM memory usage for TLS was very large. This was a result of in-place > buffers, which TLS uses, and how the code handled the combined intrinsic > method during decryption. A temporary buffer was used because

Re: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java [v2]

2022-11-21 Thread Daniel Fuchs
On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons wrote: >> Please review an update for the troff man pages, following the recent update >> to upgrade to use pandoc 2.19.2 >> (See https://bugs.openjdk.org/browse/JDK-8297165) >> >> In conjunction with this, one javadoc test also needs to be upd

Re: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java [v2]

2022-11-21 Thread Jonathan Gibbons
> Please review an update for the troff man pages, following the recent update > to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated, to work > with the new form of output generated by the new

Re: RFR: 8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions [v21]

2022-11-21 Thread Volodymyr Paprotski
On Thu, 17 Nov 2022 19:32:28 GMT, Vladimir Ivanov wrote: >> Volodymyr Paprotski has updated the pull request incrementally with one >> additional commit since the last revision: >> >> vzeroall, no spill, reg re-map > > Overall, looks good. Just one minor cleanup suggestion. > > I've submitte

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v8]

2022-11-21 Thread Maurizio Cimadamore
On Mon, 21 Nov 2022 12:50:43 GMT, Per Minborg wrote: >> Would it be possible to re-examine acquireSession returning Runnable and >> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit >> awkward at most of the use sites and maybe we can do better. > > I think it would be co

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Maurizio Cimadamore
On Mon, 21 Nov 2022 16:34:46 GMT, Alan Bateman wrote: > > Although this looks much simpler and concise, it means "a new object is > > created for each invocation" > > My comment was actually to see if DirectBuffer could extend AutoCloseable so > that the acquire returns "this" for the non-sess

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg wrote: > Although this looks much simpler and concise, it means "a new object is > created for each invocation" My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case.

Re: RFR: 8281236: (D)TLS key exchange named groups [v3]

2022-11-21 Thread Sean Mullan
On Tue, 8 Nov 2022 22:07:35 GMT, Sean Mullan wrote: >>> Unfortunately, I only have author status and can only comment. >> >> I think OpenJDK Author can approve as well. I just need to get another >> Reviewer approval before integration. > >> > Unfortunately, I only have author status and can o

Re: RFR: 8295010: Reduce if required in EC limbs operations [v5]

2022-11-21 Thread Xue-Lei Andrew Fan
On Mon, 21 Nov 2022 07:41:12 GMT, Daniel Jeliński wrote: >> Xue-Lei Andrew Fan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> remove duplicated bench test > > src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 14:07:38 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rename methods > > src/java.base/share/classes/java/util/zip/Adler32.java line 105: > >> 103: adler = u

Integrated: 8294073: Performance improvement for message digest implementations

2022-11-21 Thread Xue-Lei Andrew Fan
On Tue, 20 Sep 2022 22:12:04 GMT, Xue-Lei Andrew Fan wrote: > Hi, > > In the message digest implementation, for example SHA256, in JDK, two bitwise > operations could be improved with equivalent arithmetic, and then the number > bitwise operations could be reduced accordingly. Specifically >

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v8]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6]

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 14:14:14 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java >> >>Co-authored-by: ExE Boss <38890

Integrated: 8296399: crlNumExtVal might be null inside X509CRLSelector::match

2022-11-21 Thread Weijun Wang
On Thu, 17 Nov 2022 16:14:57 GMT, Weijun Wang wrote: > When `X509CRLSelector ` requires a CRL number extension but a CRL does not > have it, the CRL should not be selected. > > Note: the test uses a new internal API introduced in > https://github.com/openjdk/jdk/pull/11151. This pull request

Integrated: 8286575: Document how properties in java.security are parsed

2022-11-21 Thread Sean Coffey
On Thu, 17 Nov 2022 12:26:18 GMT, Sean Coffey wrote: > A doc edit to indicate that modifications of values in java.security conf > file would require a JVM restart in order for such changes to be detected. This pull request has now been integrated. Changeset: d0a7938e Author:Sean Coffey U

Re: RFR: 8286575: Document how properties in java.security are parsed [v2]

2022-11-21 Thread Sean Mullan
On Mon, 21 Nov 2022 09:38:41 GMT, Sean Coffey wrote: >> A doc edit to indicate that modifications of values in java.security conf >> file would require a JVM restart in order for such changes to be detected. > > Sean Coffey has updated the pull request incrementally with one additional > commit

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6]

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed by

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed by

Re: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6]

2022-11-21 Thread Weijun Wang
On Mon, 21 Nov 2022 00:29:34 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional > commit since the last revision: > > Modify as review and update copyright. Looks almost

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v7]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 13:32:43 GMT, ExE Boss wrote: >> Per Minborg has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Rename methods > > src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41: > >> 39: // An example of a guarde

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread ExE Boss
On Mon, 21 Nov 2022 13:43:56 GMT, Per Minborg wrote: >> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41: >> >>> 39: // An example of a guarded use of a memory address is shown here: >>> 40: // >>> 41: // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb))

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v5]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread ExE Boss
On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed by

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v3]

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 12:19:21 GMT, Alan Bateman wrote: >> maybe just `bufferLock` and and just `acquireBuffer` ? > > Would it be possible to re-examine acquireSession returning Runnable and > acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit > awkward at most of the use si

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v3]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2]

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore wrote: >> Eventually, I hope most of them will be named `_`. > > maybe just `bufferLock` and and just `acquireBuffer` ? Would it be possible to re-examine acquireSession returning Runnable and acquireSessionAsAutoCloseable returning AutoClo

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2]

2022-11-21 Thread Maurizio Cimadamore
On Mon, 21 Nov 2022 12:03:35 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/util/zip/Adler32.java line 102: >> >>> 100: return; >>> 101: if (buffer.isDirect()) { >>> 102: try (var sessionAcquisition = >>> NIO_ACCESS.acquireSessionAsAutoCloseable(buff

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2]

2022-11-21 Thread Per Minborg
> This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by native memory that, in turn, can be closed asynchronously

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg wrote: >> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252: >> >>> 250: try { >>> 251: // 'dst' is guaranteed not to be associated with a >>> closeable session. >>> 252: // Hence, there is no need fo

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 11:32:35 GMT, Alan Bateman wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed b

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Per Minborg
On Mon, 21 Nov 2022 11:29:07 GMT, Alan Bateman wrote: >> This PR proposes the introduction of **guarding** of the use of >> `DirectBuffer::address` within the JDK. With the introduction of the Foreign >> Function and Memory access, it is possible to derive Buffer instances that >> are backed b

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote: > This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by nat

Re: RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Alan Bateman
On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote: > This PR proposes the introduction of **guarding** of the use of > `DirectBuffer::address` within the JDK. With the introduction of the Foreign > Function and Memory access, it is possible to derive Buffer instances that > are backed by nat

RFR: 8296024: Usage of DIrectBuffer::address should be guarded

2022-11-21 Thread Per Minborg
This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the u

Re: RFR: 8286575: Document how properties in java.security are parsed [v2]

2022-11-21 Thread Sean Coffey
On Fri, 18 Nov 2022 22:50:17 GMT, Sean Mullan wrote: >> Sean Coffey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Review comment from Sean M > > src/java.base/share/conf/security/java.security line 29: > >> 27: # an unspecified error

Re: RFR: 8286575: Document how properties in java.security are parsed [v2]

2022-11-21 Thread Sean Coffey
> A doc edit to indicate that modifications of values in java.security conf > file would require a JVM restart in order for such changes to be detected. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Review comment from Sean M -

Re: RFR: 8247645: ChaCha20 intrinsics [v3]

2022-11-21 Thread Nick Gasson
On Thu, 17 Nov 2022 18:50:48 GMT, Jamil Nimeh wrote: >> Jamil Nimeh has updated the pull request incrementally with one additional >> commit since the last revision: >> >> replace hi/lo word shuffles and left-right shift/or operations for vpshufd >> on byte-aligned rotations > > Another pair

Re: RFR: 8247645: ChaCha20 intrinsics [v4]

2022-11-21 Thread Nick Gasson
On Mon, 21 Nov 2022 06:28:32 GMT, Jamil Nimeh wrote: >> This PR delivers ChaCha20 intrinsics that accelerate the core block function >> that generates key stream from the key, counter and nonce. Intrinsics have >> been written for the following platforms and instruction sets: >> >> - x86_64:

Re: RFR: 8295010: Reduce if required in EC limbs operations [v5]

2022-11-21 Thread Xue-Lei Andrew Fan
On Mon, 21 Nov 2022 07:44:15 GMT, Daniel Jeliński wrote: > Can you share the updated benchmarks? The benchmark number in the PR description is the latest run that I have. I may run it again after the integration of multiplicative inversion and point multiplication improvement. -