From ihse at openjdk.org Thu Feb 1 09:13:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 09:13:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1920844523 From alanb at openjdk.org Thu Feb 1 12:16:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 Feb 2024 12:16:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 14:15:57 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - Restore AIX dirent64 et al defines > - Rollback AIX changes since they are now tracked in JDK-8324834 > - Remove superfluous setting of FOB64 > - Replace all foo64() with foo() for large-file functions in the JDK > - 8324539: Do not use LFS64 symbols in JDK libs I skimmed through the changes and they look okay. Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921189429 From mbaesken at openjdk.org Thu Feb 1 13:50:15 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 13:50:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge branch 'master' into jdk-FOB64 >> - Move #include out of debug_util.h >> - Restore AIX dirent64 et al defines >> - Rollback AIX changes since they are now tracked in JDK-8324834 >> - Remove superfluous setting of FOB64 >> - Replace all foo64() with foo() for large-file functions in the JDK >> - 8324539: Do not use LFS64 symbols in JDK libs > > After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). > > > diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > index 823475b0a23..ee0109b6806 100644 > --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c > @@ -31,6 +31,10 @@ > #include "SpanIterator.h" > #include "Trace.h" > > +#if defined(_AIX) && defined(open) > +#undef open > +#endif > + > /* The "header" consists of a jint opcode and a jint span count value */ > #define INTS_PER_HEADER 2 > #define BYTES_PER_HEADER 8 > @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. Unfortunately it did not help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921367368 From ihse at openjdk.org Thu Feb 1 14:21:37 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:21:37 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v5] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove all system includes from debug_util.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/d6c64bc4..6e9ec631 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=03-04 Stats: 10 lines in 4 files changed: 6 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v6] In-Reply-To: References: Message-ID: <_ZwLqLPG2IQY-9lP4XO3KlStPatpZGye-Blofj9qfQQ=.dbffd3e3-1f37-4403-92de-63740436cde2@github.com> > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - Restore AIX dirent64 et al defines - Rollback AIX changes since they are now tracked in JDK-8324834 - Remove superfluous setting of FOB64 - Replace all foo64() with foo() for large-file functions in the JDK - 8324539: Do not use LFS64 symbols in JDK libs ------------- Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05 Stats: 233 lines in 23 files changed: 14 ins; 105 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Thu Feb 1 14:27:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 14:27:15 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <3c6OBIr0CfTFj2PGPn3n3rzLkNxiNavNj-sOx5dWqTw=.64b85b44-36f1-44de-b187-93c6c94ebc9d@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. @MBaesken How annoying. :( I have now tried to remove *all* system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921455438 From mbaesken at openjdk.org Thu Feb 1 15:57:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 1 Feb 2024 15:57:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote: >> After adding this additional patch I fully build fastdebug on AIX (hav to admit it does not look very nice). >> >> >> diff --git a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> index 823475b0a23..ee0109b6806 100644 >> --- a/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> +++ b/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c >> @@ -31,6 +31,10 @@ >> #include "SpanIterator.h" >> #include "Trace.h" >> >> +#if defined(_AIX) && defined(open) >> +#undef open >> +#endif >> + >> /* The "header" consists of a jint opcode and a jint span count value */ >> #define INTS_PER_HEADER 2 >> #define BYTES_PER_HEADER 8 > >> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. > > > Unfortunately it did not help. > @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? The AIX (fast)debug build still fails . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921645170 From ihse at openjdk.org Thu Feb 1 16:21:05 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 1 Feb 2024 16:21:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: References: Message-ID: <1wzw4p_VVMn-Qkb6utSVBVN4HDK9uwRnr3MGDsxi51A=.5028d021-ecd3-45af-a9a1-2033a897cf9b@github.com> On Thu, 1 Feb 2024 12:13:08 GMT, Alan Bateman wrote: > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1921697168 From psandoz at openjdk.org Thu Feb 1 19:46:05 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 1 Feb 2024 19:46:05 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16681#pullrequestreview-1857461928 From jvernee at openjdk.org Thu Feb 1 20:10:29 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 1 Feb 2024 20:10:29 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v2] In-Reply-To: References: Message-ID: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into AlignedOffset - Add api note pointing to alternatives for client that require non-plain access - simplify spec for alignmentOffset and alignedSlice - Merge note about misaligned access in byteBufferViewVarHandle - updated alignedSlice implNote as well - updated alignedOffset implNote - Use ISE for bbvvh instead of UOE - restore some tests for direct buffers - fix BAVV and BBVV impl and tests - regen test files - ... and 1 more: https://git.openjdk.org/jdk/compare/0468810a...eccf4f41 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16681/files - new: https://git.openjdk.org/jdk/pull/16681/files/d74f47f1..eccf4f41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=00-01 Stats: 235568 lines in 5388 files changed: 128775 ins; 77246 del; 29547 mod Patch: https://git.openjdk.org/jdk/pull/16681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16681/head:pull/16681 PR: https://git.openjdk.org/jdk/pull/16681 From mcimadamore at openjdk.org Thu Feb 1 21:54:06 2024 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 1 Feb 2024 21:54:06 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v2] In-Reply-To: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> References: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> Message-ID: On Thu, 1 Feb 2024 20:10:29 GMT, Jorn Vernee wrote: >> See the JBS issue for an extended problem description. >> >> This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). >> >> - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. >> >> - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. >> >> - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: >> >> >> * @throws UnsupportedOperationException >> * If the native platform does not guarantee stable alignment offset >> * values for the given unit size when managing the memory regions >> * of buffers of the same kind as this buffer (direct or >> * non-direct). For example, if garbage collection would... > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into AlignedOffset > - Add api note pointing to alternatives for client that require non-plain access > - simplify spec for alignmentOffset and alignedSlice > - Merge note about misaligned access in byteBufferViewVarHandle > - updated alignedSlice implNote as well > - updated alignedOffset implNote > - Use ISE for bbvvh instead of UOE > - restore some tests for direct buffers > - fix BAVV and BBVV impl and tests > - regen test files > - ... and 1 more: https://git.openjdk.org/jdk/compare/da4eca34...eccf4f41 Marked as reviewed by mcimadamore (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16681#pullrequestreview-1857716614 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add kludge to BufferedRenderPipe.c for AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/eb92119e..3c404183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=05-06 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Fri Feb 2 06:55:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 06:55:19 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v4] In-Reply-To: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> References: <7M86DsSoWaLOQmf_cK6mXD4hTI8NZ356Z7ZRugqETzM=.bb90569d-0386-4498-9f21-d4c7e66f864f@github.com> Message-ID: On Thu, 1 Feb 2024 15:54:40 GMT, Matthias Baesken wrote: >>> @MBaesken So my fix in [25c691d](https://github.com/openjdk/jdk/pull/17538/commits/25c691df823eb9d9db1451637f28d59dd9508386) did not help? Maybe then it is some other system library that drags in `fcntl.h`; I assumed it was stdlib or stdio. That header file includes way too much that it does not need, so we can surely strip it of even more standard includes if that is what is required to fix this. >> >> >> Unfortunately it did not help. > >> @MBaesken How annoying. :( I have now tried to remove _all_ system includes from `debug_util.h`. Can you please try again building debug on AIX, to see if it works without the `#undef` in `BufferedRenderPipe.c`? > > The AIX (fast)debug build still fails . @MBaesken Ok, I officially give up. :-( I added your patch from https://github.com/openjdk/jdk/pull/17538#issuecomment-1918699480. I agree that it is not elegant, but at least it works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923062901 From duke at openjdk.org Fri Feb 2 07:01:05 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:01:05 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX First, huge thanks for doing this. I did have a very rough cut of this locally which I'd put to one side, and you and I have done essentially the same thing (but yours with more tact). That's a positive sign. > > Can you confirm that you've run tier1-4 at least? Some of the library code that is changed here is not tested in the lower tiers. > > I have run tier1-4 now, and it passes (bar the tests that are currently failing in mainline). However, this only tests 64-bit builds, and these changes do not affect 64-bit builds, only 32-bit linux. So the tier1-4 is more of a sanity check that I did not inadvertenly broke any 64-bit code. > > To really test that this works properly, a 32-bit linux with an assortment of operations on > 2GB files would be needed. To the best of my knowledge, we have no such test environment available, and I could not even try to think of how to create such a test setup that does anything useful. (That is, if I even were to spend any time on creating new tests for 32-bit platforms...) Yeah, let's not, I think. The only way of doing this is with libc shims and a huge mess. As long as we have tests which handle > 2GB files in general, and then also we can get someone to run this on a 32-bit system and tell us if the test suite passes as-is, then we're fine. Really, even if it builds on a 32-bit system with strict `-Werror=x` for pointer conversions and such, then we're OK. I'll leave comments inline for the rest. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1923093781 From duke at openjdk.org Fri Feb 2 07:05:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:05:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX make/modules/jdk.hotspot.agent/Lib.gmk line 31: > 29: > 30: ifeq ($(call isTargetOs, linux), true) > 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 We have two choices to feel a bit more comfortable: 1) We unconditionally `static_assert` in a few places for large `off_t`, or 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > 92: return IOS_UNSUPPORTED_CASE; > 93: > 94: loff_t offset = (loff_t)position; Is this `loff_t` for the benefit of `copy_file_range`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475635336 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475636686 From duke at openjdk.org Fri Feb 2 07:10:07 2024 From: duke at openjdk.org (Sam James) Date: Fri, 2 Feb 2024 07:10:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > 363: #else > 364: // Make sure we link to the 64-bit version of the functions > 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1475642841 From ihse at openjdk.org Fri Feb 2 15:53:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> On Fri, 2 Feb 2024 07:02:43 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c line 94: > >> 92: return IOS_UNSUPPORTED_CASE; >> 93: >> 94: loff_t offset = (loff_t)position; > > Is this `loff_t` for the benefit of `copy_file_range`? That is how copy_file_range is defined. The cast to off64_t was technically incorrect (but they ended up being the same type). > src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: > >> 363: #else >> 364: // Make sure we link to the 64-bit version of the functions >> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); > > Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) I wrote earlier: > There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476232283 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476229335 From ihse at openjdk.org Fri Feb 2 15:53:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:53:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> References: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> Message-ID: On Fri, 2 Feb 2024 15:48:04 GMT, Magnus Ihse Bursie wrote: >> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 365: >> >>> 363: #else >>> 364: // Make sure we link to the 64-bit version of the functions >>> 365: my_openat_func = (openat_func*) dlsym(RTLD_DEFAULT, "openat64"); >> >> Explain this part to me, if you wouldn't mind? (Why do we keep the `64` variants?) > > I wrote earlier: > >> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. Even if this is incorrect, it seems at least *safe* to do it this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476231574 From ihse at openjdk.org Fri Feb 2 15:57:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Feb 2024 15:57:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Add kludge to BufferedRenderPipe.c for AIX > > make/modules/jdk.hotspot.agent/Lib.gmk line 31: > >> 29: >> 30: ifeq ($(call isTargetOs, linux), true) >> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 > > We have two choices to feel a bit more comfortable: > 1) We unconditionally `static_assert` in a few places for large `off_t`, or > 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). > > Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. I'm guessing your comment was really more general, and just happened to be placed here? The reason I am removing `-D_FILE_OFFSET_BITS=64` here is that it is always set for all JDK compilations. 1. I don't know why you would not trust that compiler flags in the build system would work, but if you really want to add a static_assert, let me know where you want it. 2. No, AIX is not handled separately. It is handled as part of this PR. You are probably thinking about JDK-8324834, but that was only about Hotspot. This PR is about all the other JDK native libraries. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1476236956 From lancea at openjdk.org Fri Feb 2 20:04:02 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 20:04:02 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bj?rsn?s wrote: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). Looks OK overall. One minor suggestion test/jdk/jdk/nio/zipfs/TestPosix.java line 757: > 755: try (FileSystem fs = FileSystems.newFileSystem(ZIP_FILE, ENV_POSIX)) { > 756: Path path = fs.getPath("hello.txt"); > 757: Files.setPosixFilePermissions(path, EnumSet.of(OWNER_READ)); It might be helpful to show the before/after output of the CEN fields here just for extra clarity ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17556#pullrequestreview-1860241911 PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476630176 From eirbjo at openjdk.org Fri Feb 2 21:20:29 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:20:29 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: For clarity, add comments with the before/after zipdetails output of the relevant CEN fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17556/files - new: https://git.openjdk.org/jdk/pull/17556/files/dabe0fb7..4bb77e1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=00-01 Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17556/head:pull/17556 PR: https://git.openjdk.org/jdk/pull/17556 From eirbjo at openjdk.org Fri Feb 2 21:20:30 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:20:30 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 20:01:06 GMT, Lance Andersen wrote: > It might be helpful to show the before/after output of the CEN fields here just for extra clarity Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for relevant fields before/after calling `setPosixFilePermissions`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476739887 From lancea at openjdk.org Fri Feb 2 21:37:11 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 21:37:11 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 21:20:29 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. >> >> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. >> >> The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. >> >> The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > For clarity, add comments with the before/after zipdetails output of the relevant CEN fields Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17556#pullrequestreview-1860426767 From lancea at openjdk.org Fri Feb 2 21:37:11 2024 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 2 Feb 2024 21:37:11 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries [v2] In-Reply-To: References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Fri, 2 Feb 2024 21:17:48 GMT, Eirik Bj?rsn?s wrote: >> test/jdk/jdk/nio/zipfs/TestPosix.java line 757: >> >>> 755: try (FileSystem fs = FileSystems.newFileSystem(ZIP_FILE, ENV_POSIX)) { >>> 756: Path path = fs.getPath("hello.txt"); >>> 757: Files.setPosixFilePermissions(path, EnumSet.of(OWNER_READ)); >> >> It might be helpful to show the before/after output of the CEN fields here just for extra clarity > >> It might be helpful to show the before/after output of the CEN fields here just for extra clarity > > Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for relevant fields before/after calling `setPosixFilePermissions`. thank you Looks good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17556#discussion_r1476753283 From eirbjo at openjdk.org Fri Feb 2 21:53:10 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Fri, 2 Feb 2024 21:53:10 GMT Subject: Integrated: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries In-Reply-To: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> References: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> Message-ID: On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bj?rsn?s wrote: > Please review this PR to fix to a regression in ZipFileSystem, introduced by JDK-8322565 in PR #17170. > > When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then `Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by JDK-8322565 did not account for this and incorrectly sets the leading seven bits to all ones instead of all zeros. > > The fix is to introduce a branch for `Entry.posixPerms` being -1 and deal with that case separately. > > The PR adds a test case to `TestPosix` which reproduces the regression. While visiting this test, I also fixed an incorrect spelling of `setPosixFilePermissions` (also introduced by #17170). This pull request has now been integrated. Changeset: a18b03b8 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/a18b03b86fdd0eef773badbced46607a8e5a068a Stats: 51 lines in 2 files changed: 49 ins; 0 del; 2 mod 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/17556 From darcy at openjdk.org Fri Feb 2 23:41:11 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 23:41:11 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base Message-ID: After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. ------------- Commit messages: - JDK-8325189: Enable this-escape javac warning in java.base Changes: https://git.openjdk.org/jdk/pull/17692/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325189 Stats: 151 lines in 93 files changed: 149 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692 PR: https://git.openjdk.org/jdk/pull/17692 From darcy at openjdk.org Fri Feb 2 23:41:11 2024 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 Feb 2024 23:41:11 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1924907536 From darcy at openjdk.org Sat Feb 3 01:37:03 2024 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 3 Feb 2024 01:37:03 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote: > In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. > PS Builds pass on all platforms (linux, mac, and windows) on Oracle's internal build system. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1925001815 From alanb at openjdk.org Sun Feb 4 06:58:03 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 4 Feb 2024 06:58:03 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. I skimmed through the use sites and don't see any issues. There is one bucket of escaping "this" that will go away once the support for running with the SM goes away. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1861282672 From eirbjo at openjdk.org Sun Feb 4 16:36:13 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 16:36:13 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows Message-ID: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. ------------- Commit messages: - TestPosix.setPermissionsShouldConvertToUnix fails intermittently on Windows. Disable for now. Changes: https://git.openjdk.org/jdk/pull/17700/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17700&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325201 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17700/head:pull/17700 PR: https://git.openjdk.org/jdk/pull/17700 From lancea at openjdk.org Sun Feb 4 18:18:00 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 4 Feb 2024 18:18:00 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows In-Reply-To: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 16:22:14 GMT, Eirik Bj?rsn?s wrote: > Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? > > This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) > > To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. Hi Eirik, I think disabling the tests makes sense for now or perhaps just disable for windows. I think we should use a separate PR to disable the test and keep this bug open ------------- PR Review: https://git.openjdk.org/jdk/pull/17700#pullrequestreview-1861535931 From eirbjo at openjdk.org Sun Feb 4 18:26:00 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 18:26:00 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows In-Reply-To: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: <76K4srQ3XhKdotP9ujXbbwdFyCx_D3gdLZJAbpZqe2g=.d9ab5c91-7dfb-4187-b7aa-7762c1ee4636@github.com> On Sun, 4 Feb 2024 16:22:14 GMT, Eirik Bj?rsn?s wrote: > Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? > > This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) > > To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. > I think we should use a separate PR to disable the test and keep this bug open Lance, I did create a separate issue for this PR to disable the test. We can keep the other bug open, yes. Or did I misunderstand something here..? I?m not sure how to disable this test specially for Windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17700#issuecomment-1925872704 From lancea at openjdk.org Sun Feb 4 19:26:03 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 4 Feb 2024 19:26:03 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows In-Reply-To: <76K4srQ3XhKdotP9ujXbbwdFyCx_D3gdLZJAbpZqe2g=.d9ab5c91-7dfb-4187-b7aa-7762c1ee4636@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> <76K4srQ3XhKdotP9ujXbbwdFyCx_D3gdLZJAbpZqe2g=.d9ab5c91-7dfb-4187-b7aa-7762c1ee4636@github.com> Message-ID: On Sun, 4 Feb 2024 18:23:45 GMT, Eirik Bj?rsn?s wrote: > > I think we should use a separate PR to disable the test and keep this bug open > > Lance, > > I did create a separate issue for this PR to disable the test. We can keep the other bug open, yes. Or did I misunderstand something here..? Hi Eirik, Apologies for not being clearer Sorry I missed that, thank you :-) > > I?m not sure how to disable this test specially for Windows. You could: ` private static final boolean isWindows = System.getProperty("os.name") .startsWith("Windows"); ` and in the test: if(isWindows) { return; } You could also use the jtreg SkippedException import jtreg.SkippedException; if(isWindows) { throw new SkippedException("Running on windows, temporarily by-passing running this test"); } See the [JTREG FAQ](https://openjdk.org/jtreg/faq.html) 4.34 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17700#issuecomment-1925888483 From eirbjo at openjdk.org Sun Feb 4 20:35:24 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 20:35:24 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows [v2] In-Reply-To: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: > Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? > > This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) > > To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Selectively skip the test only on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17700/files - new: https://git.openjdk.org/jdk/pull/17700/files/3adb75d3..b09472c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17700&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17700&range=00-01 Stats: 8 lines in 2 files changed: 6 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17700/head:pull/17700 PR: https://git.openjdk.org/jdk/pull/17700 From eirbjo at openjdk.org Sun Feb 4 20:35:24 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 20:35:24 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows In-Reply-To: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 16:22:14 GMT, Eirik Bj?rsn?s wrote: > Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? > > This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) > > To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. Thanks Lance, I've pushed a commit which skips the test selectively on Windows. Since this test runs with a security manager, I needed to add a property read permission for `os.name`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17700#issuecomment-1925905861 From lancea at openjdk.org Sun Feb 4 20:54:00 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 4 Feb 2024 20:54:00 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows [v2] In-Reply-To: References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 20:35:24 GMT, Eirik Bj?rsn?s wrote: >> Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix`? >> >> This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) >> >> To reduce CI noise, I suggest we simply add `@Disabled` for now on the failing test. The actual fix of the failing test will be investigated and fixed as a follow-up PR. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Selectively skip the test only on Windows Thank you for the update Eirik, That looks good. I would also link this bug to the open bug in JBS when you have a moment, ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17700#pullrequestreview-1861555802 From eirbjo at openjdk.org Sun Feb 4 20:59:00 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 20:59:00 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows [v2] In-Reply-To: References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 20:51:09 GMT, Lance Andersen wrote: > I would also link this bug to the open bug in JBS when you have a moment This bug, [8325201](https://bugs.openjdk.org/browse/JDK-8325201) already has a "related to" link to the open test failure bug [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199). Does that look OK to you, or did you mean something else? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17700#issuecomment-1925911726 From eirbjo at openjdk.org Sun Feb 4 21:04:05 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 21:04:05 GMT Subject: Integrated: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows In-Reply-To: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 16:22:14 GMT, Eirik Bj?rsn?s wrote: > Can I please get a review for this trivial change to disable the test `TestPosix.setPermissionsShouldConvertToUnix` on Windows? > > This test was recently introduced in [JDK-8324635](https://bugs.openjdk.org/browse/JDK-8324635), but fails intermittently on Windows CI runs. (See [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199)) > > To reduce CI noise, I suggest we simply disable this test on Windows for now. The actual fix of the failing test will be investigated and fixed as a follow-up PR. This pull request has now been integrated. Changeset: 692c9f88 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/692c9f8821e220560927dd6bbedfea9ddfe312f6 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/17700 From lancea at openjdk.org Sun Feb 4 21:20:03 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 4 Feb 2024 21:20:03 GMT Subject: RFR: 8325201: (zipfs) Disable TestPosix.setPermissionsShouldConvertToUnix which fails on Windows [v2] In-Reply-To: References: <9wNfTPojtdlycp6HUZ9PIGSyyApXrV0Lw7BrKLFqq3w=.a494140e-aae3-4202-ad40-5f943c680483@github.com> Message-ID: On Sun, 4 Feb 2024 20:56:42 GMT, Eirik Bj?rsn?s wrote: > > I would also link this bug to the open bug in JBS when you have a moment > > This bug, [8325201](https://bugs.openjdk.org/browse/JDK-8325201) already has a "related to" link to the open test failure bug [JDK-8325199](https://bugs.openjdk.org/browse/JDK-8325199). > > Does that look OK to you, or did you mean something else? It looks fine, I checked before I submitted the approval so must have been a timing issue. Thank you for the above ------------- PR Comment: https://git.openjdk.org/jdk/pull/17700#issuecomment-1925917097 From eirbjo at openjdk.org Sun Feb 4 21:41:19 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 4 Feb 2024 21:41:19 GMT Subject: RFR: 8325199: (zipfs) jdk/nio/zipfs/TestPosix.java failed 6 sub-tests Message-ID: Please review this PR which fixes an intermittent failure on Windows for the `TestPosix` test. The recently introduced test `setPermissionsShouldConvertToUnix` fails to close the `FileSystem` returned by `createEmptyZipFile`. The solution is to move this call within the 'try-with-resources' statement, ensuring it gets properly closed. Besides fixing the underlying file resource management issue, this PR also re-enables this test on Windows. Since the author failed to realize that the method `createEmptyZipFile` returns an open FileSystem, this PR also suggests that we rename this method to `createEmptyZipFileSystem` in the hope that it will reduce future confusion. ------------- Commit messages: - Note that the caller is responsible for closing the FileSystem returned by createEmptyZipFileSystem - Re-enable the setPermissionsShouldConvertToUnix test on Windows - createEmptyZipFile returns an open FileSystem, make sure we close it in a try-with-resources Changes: https://git.openjdk.org/jdk/pull/17702/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17702&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325199 Stats: 13 lines in 2 files changed: 1 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17702.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17702/head:pull/17702 PR: https://git.openjdk.org/jdk/pull/17702 From clanger at openjdk.org Sun Feb 4 22:26:00 2024 From: clanger at openjdk.org (Christoph Langer) Date: Sun, 4 Feb 2024 22:26:00 GMT Subject: RFR: 8325199: (zipfs) jdk/nio/zipfs/TestPosix.java failed 6 sub-tests In-Reply-To: References: Message-ID: <6Wcgev89Mukx5_f0-BG9_AhiS9U4SWLofdPhfX2w2yw=.8566fc41-a341-43d6-b069-f964f10645c9@github.com> On Sun, 4 Feb 2024 21:23:39 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which fixes an intermittent failure on Windows for the `TestPosix` test. > > The recently introduced test `setPermissionsShouldConvertToUnix` fails to close the `FileSystem` returned by `createEmptyZipFile`. The solution is to move this call within the 'try-with-resources' statement, ensuring it gets properly closed. > > Besides fixing the underlying file resource management issue, this PR also re-enables this test on Windows. > > Since the author failed to realize that the method `createEmptyZipFile` returns an open FileSystem, this PR also suggests that we rename this method to `createEmptyZipFileSystem` in the hope that it will reduce future confusion. Looks good. Thanks for fixing the test. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17702#pullrequestreview-1861589938 From duke at openjdk.org Mon Feb 5 01:24:10 2024 From: duke at openjdk.org (Marcono1234) Date: Mon, 5 Feb 2024 01:24:10 GMT Subject: RFR: 8316337: (bf) Concurrency issue in DirectByteBuffer.Deallocator [v4] In-Reply-To: References: Message-ID: On Tue, 19 Sep 2023 06:33:08 GMT, Per Minborg wrote: >> This PR proposes to make fields of implementations of the interface `DirectByteBuffer.Deallocator` `final` ensuring safe publication and immutability. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Make unmappers truly immutable > - Revert to anonymous UmapperProxy class src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1200: > 1198: return; > 1199: nd.unmap(address, size); > 1200: address = 0; To be safe, would it make sense to keep this code? For `DirectByteBuffer$Deallocator` you can easily verify that it is safe because the class is only used to create a `Cleaner` (and `Deallocator` is private). However, here for `Unmapper` `unmap()` is a public method which can be called from other classes through `UnmapperProxy` (currently called by `FileChannelLinesSpliterator#unmap`), and there is also `Unmapper#run` which calls `unmap`. Possibly the current code is still safe and no double-unmap is possible, but verifying this, and ensuring that this remains the case in the future seems difficult. So this additional safeguard here seems useful (at least in my opinion). (Sorry for this super late comment) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15784#discussion_r1477544435 From mbaesken at openjdk.org Mon Feb 5 08:29:06 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 08:29:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <7R-vR6xRkCutTiGye-lVtYvEjWVKLFYDWFCaj-Drcbc=.963a2048-d87a-4f4e-b93e-79a62b432138@github.com> On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I noticed that in the file src/java.base/share/native/libzip/zlib/zconf.h we seem to still use `off64_t` , is this okay (at most other locations it was replaced) https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libzip/zlib/zconf.h#L541 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926448109 From ihse at openjdk.org Mon Feb 5 09:19:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 09:19:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX zlib is 3rd party source, I did not touch those. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926532998 From lancea at openjdk.org Mon Feb 5 11:51:01 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 5 Feb 2024 11:51:01 GMT Subject: RFR: 8325199: (zipfs) jdk/nio/zipfs/TestPosix.java failed 6 sub-tests In-Reply-To: References: Message-ID: On Sun, 4 Feb 2024 21:23:39 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which fixes an intermittent failure on Windows for the `TestPosix` test. > > The recently introduced test `setPermissionsShouldConvertToUnix` fails to close the `FileSystem` returned by `createEmptyZipFile`. The solution is to move this call within the 'try-with-resources' statement, ensuring it gets properly closed. > > Besides fixing the underlying file resource management issue, this PR also re-enables this test on Windows. > > Since the author failed to realize that the method `createEmptyZipFile` returns an open FileSystem, this PR also suggests that we rename this method to `createEmptyZipFileSystem` in the hope that it will reduce future confusion. Thank you for the update Eirik, the changes look good. I pulled the changes over and kicked off an internal Mach5 run. Will let you know once it finishes ------------- PR Review: https://git.openjdk.org/jdk/pull/17702#pullrequestreview-1862526003 From mbaesken at openjdk.org Mon Feb 5 12:10:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:10:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926848063 From jkern at openjdk.org Mon Feb 5 12:20:07 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 5 Feb 2024 12:20:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote: > Current commit compiles nicely on AIX. One issue we might still have statvfs/statvfs64 is not mentioned here in the table of functions/structs redefined on AIX https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files so would we fall back to statvfs from the *64 - variant ? The define _LARGE_FILES might not help in this case on AIX . Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926865295 From mbaesken at openjdk.org Mon Feb 5 12:25:07 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:25:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote: > Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on AIX to 32-Bit. _LARGE_FILES really does not help in this case! Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64 variant needs to stay on AIX. Seems the other symbols are covered by _LARGE_FILES according to the table in the linked IBM AIX doc (table in https://www.ibm.com/docs/en/aix/7.1?topic=volumes-writing-programs-that-access-large-files ) , is that correct (Joachim?) or did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926874075 From ihse at openjdk.org Mon Feb 5 12:41:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 12:41:11 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926903203 From mbaesken at openjdk.org Mon Feb 5 12:51:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 12:51:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <_bDxv8SN2pD8KNWdhQ4SsTJMkbNyA2m9ERs87kg_yIk=.d76dcb5f-8f11-4515-ab0c-ceff66c09ffa@github.com> On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote: > It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef _ALLBSD_SOURCE`, which I presume is not defined on AIX. > > I recommend that I push this PR as-is first, and then you can do a follow-up fix to define statvfs to statvfs64 on AIX. Java_sun_nio_fs_UnixNativeDispatcher_statvfs0 is changed from statvfs64 to statvfs, did I miss something ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1926925394 From ihse at openjdk.org Mon Feb 5 13:58:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 13:58:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX RIght, my bad. I apologize, you are completely correct, I turned the defines around in my head. I will add a redefine for AIX that turns statvfs into statvfs64. Thanks for noticing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927065583 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 06:55:19 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add kludge to BufferedRenderPipe.c for AIX I hope finally the AIX part of this PR is done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927082091 From ihse at openjdk.org Mon Feb 5 14:06:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 Feb 2024 14:06:21 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Redefine statvfs as statvfs64 on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/3c404183..2de377cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=06-07 Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From mbaesken at openjdk.org Mon Feb 5 14:18:08 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 5 Feb 2024 14:18:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote: > I hope finally the AIX part of this PR is done. Thanks for the AIX related effort ; I put it again into our internal build/test queue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669 From erikj at openjdk.org Mon Feb 5 15:12:01 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 5 Feb 2024 15:12:01 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863050713 From naoto at openjdk.org Mon Feb 5 23:49:48 2024 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Feb 2024 23:49:48 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863359999 From smarks at openjdk.org Mon Feb 5 23:49:52 2024 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 5 Feb 2024 23:49:52 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: <3ItCUEGtxTObo5TxNsOIPfMr15fWdQPm3CAi7eNcOv4=.506a52bb-ad1a-429a-9906-5ae1dccfdad2@github.com> On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Changes in java.util and java.util.concurrent look fine. There are a startling number of places where `this` is potentially leaked to a subclass. It would be interesting to analyze the pathologies and have a discussion of potential fixes. There may also be compatibility issues with potential fixes (nothing in this PR that I can see) because the behavior can change from the point of view of subclasses. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1863853251 From darcy at openjdk.org Mon Feb 5 23:49:58 2024 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Feb 2024 23:49:58 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote: > In its initial form, the changes are tested on Linux. Later on, I'll do cross-platform builds to make sure there aren't any, say, windows-specific changes that are needed as well. > > I can file a follow-up umbrella bug with the original list of ~200 warnings so the constructors and initializers in question can be examined to see if they should be updated. Filed [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1928049947 From mbaesken at openjdk.org Tue Feb 6 08:07:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 08:07:22 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote: > > Thanks for the AIX related effort ; I put it again into our internal build/test queue. With the latest commit the build again fails on AIX with this error /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] result = fstatvfs(fd, &file_stat); ^~~~~~~~~~ /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here extern int fstatvfs(int, struct statvfs *); ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928972961 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also fix fstatvfs on AIX ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/2de377cd..1fd34b10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Tue Feb 6 08:18:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 08:18:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v8] In-Reply-To: References: Message-ID: On Mon, 5 Feb 2024 14:06:21 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Redefine statvfs as statvfs64 on AIX Yeah, I missed `fstatvfs`. ? Now, then maybe `n`th time's a charm? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1928987789 From ihse at openjdk.org Tue Feb 6 12:27:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 12:27:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Build changes look fine, but there is really a *lot* of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :( ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865022402 From mbaesken at openjdk.org Tue Feb 6 14:01:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 6 Feb 2024 14:01:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also fix fstatvfs on AIX AIX build is fixed now after latest commit, thanks for handling the AIX special cases. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1865270571 From dfuchs at openjdk.org Tue Feb 6 14:41:56 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Feb 2024 14:41:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. I looked at the modifications in java.net / sun.net. Looks generally good though I have some comments. src/java.base/share/classes/java/net/Socket.java line 323: > 321: * @see SecurityManager#checkConnect > 322: */ > 323: @SuppressWarnings("this-escape") This is a weird one. I guess the issue here is that the escape happens in the chained constructor, and is propagated recursively up the constructor chain. Is the suppress warning here still needed after disabling this-escape warning at line 358? Actually - these are all weird since the only place where the escape happens is in the private constructor at line 548 - and it doesn't even get flagged there (presumably because it's a private constructor?) I guess that the rationale is that subclasses cannot override the private constructor (where the escape happen), but can override the public constructor that calls the private constructor where the escape happen. I can't help feeling that the warning would be better placed on the private constructor though. Seeing it here confused me a lot. src/java.base/share/classes/sun/net/www/MessageHeader.java line 53: > 51: } > 52: > 53: @SuppressWarnings("this-escape") An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged? ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1865378355 PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479922189 PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1479936447 From ihse at openjdk.org Tue Feb 6 16:13:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 Feb 2024 16:13:01 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 07:01:33 GMT, Sam James wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Also fix fstatvfs on AIX > > make/modules/jdk.hotspot.agent/Lib.gmk line 31: > >> 29: >> 30: ifeq ($(call isTargetOs, linux), true) >> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 > > We have two choices to feel a bit more comfortable: > 1) We unconditionally `static_assert` in a few places for large `off_t`, or > 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). > > Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1480125790 From darcy at openjdk.org Tue Feb 6 17:31:54 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Feb 2024 17:31:54 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs wrote: >> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. > > src/java.base/share/classes/sun/net/www/MessageHeader.java line 53: > >> 51: } >> 52: >> 53: @SuppressWarnings("this-escape") > > An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged? I'd prefer if that kind of change were done as a subtask of [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480307107 From darcy at openjdk.org Tue Feb 6 17:43:56 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Feb 2024 17:43:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. > Build changes look fine, but there is really a _lot_ of places where the warning is individually disabled. This indicates either that the warning is too broad, or that the code base is potentially very buggy; neither of which sounds very good. :( I deliberately choose to suppress the warning at each constructor location rather than at the class level so there are more SuppressWarnings annotations than strictly needed to get the build to be clean. However, I thought limiting the scope of the annotations was preferable for several reasons, including more precisely indicating where any code updates are needed. This is a new warning run over old code, in some cases very old code. I don't find it surprising that there were several hundred instances of this warning in java.base given the amount of code there. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1930451875 From joehw at openjdk.org Tue Feb 6 18:07:56 2024 From: joehw at openjdk.org (Joe Wang) Date: Tue, 6 Feb 2024 18:07:56 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. The two XML changes look good to me. There would be a lot of warnings in the java.xml module as well, if we had to do it in the future. ------------- Marked as reviewed by joehw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866004351 From lancea at openjdk.org Tue Feb 6 18:13:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 6 Feb 2024 18:13:54 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1866015274 From dfuchs at openjdk.org Tue Feb 6 18:20:54 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Feb 2024 18:20:54 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 17:29:25 GMT, Joe Darcy wrote: >> src/java.base/share/classes/sun/net/www/MessageHeader.java line 53: >> >>> 51: } >>> 52: >>> 53: @SuppressWarnings("this-escape") >> >> An alternative here could be to make the class final. AFAICS it's not subclassed anywhere. If you'd prefer not to do this here then maybe a followup issue could be logged? > > I'd prefer if that kind of change were done as a subtask of > > [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263): Address this-escape lint warnings java.base (umbrella) Thanks Joe. I logged [JDK-8325361](https://bugs.openjdk.org/browse/JDK-8325361): Make sun.net.www.MessageHeader final ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17692#discussion_r1480362736 From bpb at openjdk.org Wed Feb 7 00:35:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Feb 2024 00:35:03 GMT Subject: RFR: 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target Message-ID: When replacing an existing file as part of a non-atomic copy (`Files.copy`) or move (`Files.move`), ignore any file not found error encountered while trying to delete the target file. ------------- Commit messages: - 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target Changes: https://git.openjdk.org/jdk/pull/17740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17740&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325302 Stats: 24 lines in 2 files changed: 14 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17740/head:pull/17740 PR: https://git.openjdk.org/jdk/pull/17740 From bpb at openjdk.org Wed Feb 7 00:35:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Feb 2024 00:35:03 GMT Subject: RFR: 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 00:28:25 GMT, Brian Burkhalter wrote: > When replacing an existing file as part of a non-atomic copy (`Files.copy`) or move (`Files.move`), ignore any file not found error encountered while trying to delete the target file. A target file being replaced might be verified to exist at a point in time prior to when an attempt is actually made to delete it, so if the file is deleted by some other entity in the intervening time, a file not found error will occur during the deletion call. In this case, an error indicating that the file does not exist (cannot be found) should simply be ignored. The correctness of the changes were verified manually. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17740#issuecomment-1931020438 From alanb at openjdk.org Wed Feb 7 07:39:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Feb 2024 07:39:54 GMT Subject: RFR: 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target In-Reply-To: References: Message-ID: <_Nn38AoZXq9Slbzxz-oIdb4tUwkXFGurqzpaVkFgccg=.d0e84523-b4ab-42a9-b293-4c5e7af922f9@github.com> On Wed, 7 Feb 2024 00:28:25 GMT, Brian Burkhalter wrote: > When replacing an existing file as part of a non-atomic copy (`Files.copy`) or move (`Files.move`), ignore any file not found error encountered while trying to delete the target file. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17740#pullrequestreview-1867074735 From alanb at openjdk.org Wed Feb 7 11:45:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Feb 2024 11:45:04 GMT Subject: RFR: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread Message-ID: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> The Unix implementation of the Pipe source/sink channels eagerly configures the underlying socket to be non-blocking in case the pipe is used by a virtual thread. It can be done lazily, as done with the network channels. No changes to the semantics of the APIs, and well tested by the existing tests. ------------- Commit messages: - Update copyright dates - Merge - Initial commit Changes: https://git.openjdk.org/jdk/pull/17648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325028 Stats: 84 lines in 2 files changed: 70 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17648.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17648/head:pull/17648 PR: https://git.openjdk.org/jdk/pull/17648 From alanb at openjdk.org Wed Feb 7 12:56:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Feb 2024 12:56:12 GMT Subject: RFR: 8325399: Add tests for virtual threads doing Selector operations Message-ID: This PR adds a new test to exercise virtual threads doing Selector operations. The test has been in the loom repo for some time as there are changes in that repo to integrate some of the Selector implementations with the poller mechanism. The test is useful to have in the main line. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/17746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325399 Stats: 349 lines in 1 file changed: 349 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17746/head:pull/17746 PR: https://git.openjdk.org/jdk/pull/17746 From jkern at openjdk.org Wed Feb 7 15:56:00 2024 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 7 Feb 2024 15:56:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v9] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Also fix fstatvfs on AIX My apologies the additional defines `#define DIR DIR64` `#define dirent dirent64` `#define opendir opendir64` `#define readdir readdir64` `#define closedir closedir64` are not necessary. Indeed they do not react on _LARGE_FILES, but the DIR struct and the functions are automatically 64 when compiling in 64bit mode (-m64) as we do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1932343048 From bpb at openjdk.org Wed Feb 7 17:04:58 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Feb 2024 17:04:58 GMT Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) [v4] In-Reply-To: <2rdSqg9wJiKXpdxhatwIprCSFmosoDaABVF8A8mkDjI=.bfdfe79a-afef-4c94-8945-4993ab5bba9e@github.com> References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com> <2rdSqg9wJiKXpdxhatwIprCSFmosoDaABVF8A8mkDjI=.bfdfe79a-afef-4c94-8945-4993ab5bba9e@github.com> Message-ID: On Tue, 14 Nov 2023 19:44:55 GMT, Brian Burkhalter wrote: >> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge > - Merge > - 8315273: Add bug ID to test > - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win) continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-1932491272 From bpb at openjdk.org Wed Feb 7 18:14:54 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Feb 2024 18:14:54 GMT Subject: RFR: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread In-Reply-To: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> References: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> Message-ID: On Wed, 31 Jan 2024 09:03:14 GMT, Alan Bateman wrote: > The Unix implementation of the Pipe source/sink channels eagerly configures the underlying socket to be non-blocking in case the pipe is used by a virtual thread. It can be done lazily, as done with the network channels. No changes to the semantics of the APIs, and well tested by the existing tests. Looks okay. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17648#pullrequestreview-1868483145 From bpb at openjdk.org Wed Feb 7 19:04:57 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Feb 2024 19:04:57 GMT Subject: Integrated: 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 00:28:25 GMT, Brian Burkhalter wrote: > When replacing an existing file as part of a non-atomic copy (`Files.copy`) or move (`Files.move`), ignore any file not found error encountered while trying to delete the target file. This pull request has now been integrated. Changeset: 299a8ee6 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/299a8ee68d2dc433fa4b7ad14e2518aebab4cfac Stats: 24 lines in 2 files changed: 14 ins; 2 del; 8 mod 8325302: Files.move(REPLACE_EXISTING) throws NoSuchFileException on deleted target Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17740 From weijun at openjdk.org Wed Feb 7 19:08:54 2024 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 Feb 2024 19:08:54 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com> On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17692#pullrequestreview-1868572210 From darcy at openjdk.org Wed Feb 7 19:28:11 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 Feb 2024 19:28:11 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base [v2] In-Reply-To: References: Message-ID: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into JDK-8325189 - JDK-8325189: Enable this-escape javac warning in java.base ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17692/files - new: https://git.openjdk.org/jdk/pull/17692/files/8a160a7c..e1d56388 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=00-01 Stats: 5575 lines in 160 files changed: 3404 ins; 1290 del; 881 mod Patch: https://git.openjdk.org/jdk/pull/17692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692 PR: https://git.openjdk.org/jdk/pull/17692 From darcy at openjdk.org Wed Feb 7 20:08:18 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 Feb 2024 20:08:18 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base [v3] In-Reply-To: References: Message-ID: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8325189 - Merge branch 'master' into JDK-8325189 - JDK-8325189: Enable this-escape javac warning in java.base ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17692/files - new: https://git.openjdk.org/jdk/pull/17692/files/e1d56388..bc6cdfc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17692&range=01-02 Stats: 1057 lines in 91 files changed: 598 ins; 167 del; 292 mod Patch: https://git.openjdk.org/jdk/pull/17692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17692/head:pull/17692 PR: https://git.openjdk.org/jdk/pull/17692 From darcy at openjdk.org Wed Feb 7 20:08:19 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 Feb 2024 20:08:19 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base [v2] In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy wrote: >> After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. > > Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into JDK-8325189 > - JDK-8325189: Enable this-escape javac warning in java.base Thanks all for the reviews. Will integrate now after a sync with mainline and successful cross-platform build run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932778005 From darcy at openjdk.org Wed Feb 7 20:08:19 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 Feb 2024 20:08:19 GMT Subject: Integrated: JDK-8325189: Enable this-escape javac warning in java.base In-Reply-To: References: Message-ID: On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote: > After the "this-escape" lint warning was added to javac (JDK-8015831), the base module was not updated to be able to compile with this warning enabled. This PR makes the necessary changes to allow the base module to build with the warning enabled. This pull request has now been integrated. Changeset: fbd15b20 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/fbd15b20878b276ccd41128116f73b91b6d4c159 Stats: 151 lines in 93 files changed: 149 ins; 0 del; 2 mod 8325189: Enable this-escape javac warning in java.base Reviewed-by: alanb, erikj, naoto, smarks, ihse, joehw, lancea, weijun ------------- PR: https://git.openjdk.org/jdk/pull/17692 From darcy at openjdk.org Wed Feb 7 20:40:59 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 7 Feb 2024 20:40:59 GMT Subject: RFR: JDK-8325189: Enable this-escape javac warning in java.base [v3] In-Reply-To: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com> References: <25rXR-RgzW2Qib1E4ngpo8oG3E6pGJYr42QEWLi1fJw=.75e7164c-04dd-4d73-a44d-85b3a9c50406@github.com> Message-ID: On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang wrote: > Security changes look fine. Although I don't know how to remove those annotations later. A lot of compatibility impact. In case you didn't see it, the warning message are listed in an attachment on [JDK-8325263](https://bugs.openjdk.org/browse/JDK-8325263). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17692#issuecomment-1932829588 From bpb at openjdk.org Thu Feb 8 02:15:57 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 Feb 2024 02:15:57 GMT Subject: RFR: 8325399: Add tests for virtual threads doing Selector operations In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 12:33:54 GMT, Alan Bateman wrote: > This PR adds a new test to exercise virtual threads doing Selector operations. The test has been in the loom repo for some time as there are changes in that repo to integrate some of the Selector implementations with the poller mechanism. The test is useful to have in the main line. Test addition looks all right to me. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17746#pullrequestreview-1869152285 From duke at openjdk.org Thu Feb 8 04:44:02 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 04:44:02 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: <160IUiEFfgHTenlTpN4C2yL2oMdZPpV1fsK0YysXcr8=.cf71797d-9e10-4713-804e-368b481efde0@github.com> Message-ID: On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie wrote: >> I wrote earlier: >> >>> There is one change that merit highlighting: In src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e. Linux and AIX), and on AIX, respectively. This seems to me to be the safest choice, as we do not need to know if a lookup of openat would yield a 32-bit or a 64-bit version. (I frankly don't know, but I'm guessing it would yield the 32-bit version.) > > Basically, my understanding is that a call to "openat" in the source file will be converted into a call to openat64 on 32-bit platforms. When we look up the function using dlsym, I assume we need to find the 64-bit version directly. > > Even if this is incorrect, it seems at least *safe* to do it this way. The redirection is done via aliases in the headers, so you're right. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482403071 From jpai at openjdk.org Thu Feb 8 07:43:55 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Feb 2024 07:43:55 GMT Subject: RFR: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread In-Reply-To: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> References: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> Message-ID: On Wed, 31 Jan 2024 09:03:14 GMT, Alan Bateman wrote: > The Unix implementation of the Pipe source/sink channels eagerly configures the underlying socket to be non-blocking in case the pipe is used by a virtual thread. It can be done lazily, as done with the network channels. No changes to the semantics of the APIs, and well tested by the existing tests. Hello Alan, is the use of the word "socket" in the comments and the method names (and the PR title) intentional? As far as I can see the sink/source channels' underlying resources are file descriptors created out of a `pipe()` call. Do we use the term "socket" for such cases too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17648#issuecomment-1933515467 From ihse at openjdk.org Thu Feb 8 07:44:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Once more, remove AIX dirent64 et al defines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/1fd34b10..8a71e3b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=08-09 Stats: 44 lines in 7 files changed: 0 ins; 44 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From duke at openjdk.org Thu Feb 8 07:44:18 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:41:02 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines Marked as reviewed by thesamesam at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1869449960 From ihse at openjdk.org Thu Feb 8 07:44:18 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote: >>> I hope finally the AIX part of this PR is done. >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > > With the latest commit the build again fails on AIX with this error > > /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] > result = fstatvfs(fd, &file_stat); > ^~~~~~~~~~ > /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here > extern int fstatvfs(int, struct statvfs *); Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933513366 From duke at openjdk.org Thu Feb 8 07:44:18 2024 From: duke at openjdk.org (Sam James) Date: Thu, 8 Feb 2024 07:44:18 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: <7tII90EgHAAJH2eHwSx0CFV5smD9VXSUx5ffVtUtnWc=.c39a6845-2f40-4c57-bd0e-200cf77ccb28@github.com> On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie wrote: >> make/modules/jdk.hotspot.agent/Lib.gmk line 31: >> >>> 29: >>> 30: ifeq ($(call isTargetOs, linux), true) >>> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64 >> >> We have two choices to feel a bit more comfortable: >> 1) We unconditionally `static_assert` in a few places for large `off_t`, or >> 2) We only do it for platforms we know definitely support F_O_B and aren't AIX (which we've handled separately). >> >> Not sure that's strictly necessary though. Also, if something understands LARGEFILE*_SOURCE, then it probably understood F_O_B, or at least has some macro to control it. Just thinking aloud. > > @thesamesam Do you want a `static_assert`? As I said, please let me know where you want to put it. I don't think it provides much, but if it makes you feel more comfortable, I'm okay with adding it. Sorry! I think I'm okay with it as-is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1482529665 From alanb at openjdk.org Thu Feb 8 07:57:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Feb 2024 07:57:56 GMT Subject: Integrated: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread In-Reply-To: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> References: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> Message-ID: On Wed, 31 Jan 2024 09:03:14 GMT, Alan Bateman wrote: > The Unix implementation of the Pipe source/sink channels eagerly configures the underlying socket to be non-blocking in case the pipe is used by a virtual thread. It can be done lazily, as done with the network channels. No changes to the semantics of the APIs, and well tested by the existing tests. This pull request has now been integrated. Changeset: d1099033 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/d1099033ac63b9dd0dd6e3a7341db929e9e0e56e Stats: 84 lines in 2 files changed: 70 ins; 4 del; 10 mod 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/17648 From alanb at openjdk.org Thu Feb 8 07:58:59 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Feb 2024 07:58:59 GMT Subject: Integrated: 8325399: Add tests for virtual threads doing Selector operations In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 12:33:54 GMT, Alan Bateman wrote: > This PR adds a new test to exercise virtual threads doing Selector operations. The test has been in the loom repo for some time as there are changes in that repo to integrate some of the Selector implementations with the poller mechanism. The test is useful to have in the main line. This pull request has now been integrated. Changeset: 43089bf0 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/43089bf0065ce85681724d92d26709f4e3ad28ea Stats: 349 lines in 1 file changed: 349 ins; 0 del; 0 mod 8325399: Add tests for virtual threads doing Selector operations Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/17746 From alanb at openjdk.org Thu Feb 8 08:02:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Feb 2024 08:02:58 GMT Subject: RFR: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread In-Reply-To: References: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> Message-ID: On Thu, 8 Feb 2024 07:41:44 GMT, Jaikiran Pai wrote: > Hello Alan, is the use of the word "socket" in the comments and the method names (and the PR title) intentional? These channels can work with pipes or an unnamed pair of connected sockets. In the Windows implementation they use a Unix domain socket or a TCP socket, depending not on which Windows release. So I kept the comment using "socket" but you are right that it might be a bit clearer to say pipe in the Unix implementation. We can adjust this comment when next touching this area (as the changes here are already integrated). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17648#issuecomment-1933539273 From jkern at openjdk.org Thu Feb 8 09:06:03 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 09:06:03 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933630674 From mbaesken at openjdk.org Thu Feb 8 09:20:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 Feb 2024 09:20:00 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v7] In-Reply-To: References: Message-ID: <5GBUr8CF3X7ZZYPezmBQUzuWQZuk-pXRrdkS4PX6zeE=.28790345-6e6a-4b10-8767-1b3f8b44754b@github.com> On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote: >>> I hope finally the AIX part of this PR is done. >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > >> >> Thanks for the AIX related effort ; I put it again into our internal build/test queue. > > With the latest commit the build again fails on AIX with this error > > /jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c:381:27: error: incompatible pointer types passing 'struct statvfs64 *' to parameter of type 'struct statvfs *' [-Werror,-Wincompatible-pointer-types] > result = fstatvfs(fd, &file_stat); > ^~~~~~~~~~ > /usr/include/sys/statvfs.h:102:42: note: passing argument to parameter here > extern int fstatvfs(int, struct statvfs *); > Well, well... The code at least looks cleaner without these AIX defines, so I really hope that this is the end of the AIX saga, at the `n+1`th time. @MBaesken Can you rerun AIX testing with the latest commit? Latest commit looks still good on AIX. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1933652124 From pminborg at openjdk.org Thu Feb 8 09:32:57 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Feb 2024 09:32:57 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 17:49:56 GMT, Mark Sheppard wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Swith to using Unsafe > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 82: > >> 80: private static final class Deallocator implements Runnable { >> 81: >> 82: private static final long INVOKED_OFFSET = Unsafe.getUnsafe() > > There are two invocations of Unsafe.getUnsafe introduced here, while the base class Buffer has initialised the static UNSAFE (i.e. the reference used for freeMemory.) Could this static be used to replace Unsafe.getUnsafe ? Good catch! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1482665699 From pminborg at openjdk.org Thu Feb 8 09:42:55 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Feb 2024 09:42:55 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 17:58:04 GMT, Mark Sheppard wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Swith to using Unsafe > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 99: > >> 97: public void run() { >> 98: // Ensure idempotency (paranoia) >> 99: if (Unsafe.getUnsafe().compareAndSetInt(this, INVOKED_OFFSET, 0, 1)) { > > a question for my edification: is this compound statement suitably atomic to ensure synchronzied serial access to freeMemory block ? There's no danger of concurrent interleaved execution resulting in inconsistent view of the member variable via the reflective access ? The CAS operation establishes a happens-before relation between the CAS operation itself and any following operations (such as `freeMemory()`). Also, only one thread will succeed in changing the value from zero to one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1482677523 From jpai at openjdk.org Thu Feb 8 09:56:58 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Feb 2024 09:56:58 GMT Subject: RFR: 8325028: (ch) Pipe channels should lazily set socket to non-blocking mode on first use by virtual thread In-Reply-To: References: <0RZBuri6CSzGKt4Y4L1G5wQ3gY0uMDYO1bZz5yxHzXY=.56ffe1e2-4f8a-46f6-a222-f7a4d73ea1ba@github.com> Message-ID: On Thu, 8 Feb 2024 08:00:09 GMT, Alan Bateman wrote: > We can adjust this comment when next touching this area (as the changes here are already integrated). That is fine with me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17648#issuecomment-1933718398 From shade at openjdk.org Thu Feb 8 10:05:56 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 Feb 2024 10:05:56 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:40:02 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 99: >> >>> 97: public void run() { >>> 98: // Ensure idempotency (paranoia) >>> 99: if (Unsafe.getUnsafe().compareAndSetInt(this, INVOKED_OFFSET, 0, 1)) { >> >> a question for my edification: is this compound statement suitably atomic to ensure synchronzied serial access to freeMemory block ? There's no danger of concurrent interleaved execution resulting in inconsistent view of the member variable via the reflective access ? > > The CAS operation establishes a happens-before relation between the CAS operation itself and any following operations (such as `freeMemory()`). Also, only one thread will succeed in changing the value from zero to one. CAS block provides mutual exclusion here, as in, only one thread would ever execute the `freeMemory`/`unreserveMemory` block, which also does not modify any of the fields here. The only (?) thing we might be concerned with is that while one thread is running in the block, another thread would come and bypass the block. If anything relies on memory being actually freed after we exit `run()`, it might subtly misbehave -- accounting code, maybe? I guess a safer way to do this would be acquiring a lock, and checking `invoked` while holding it? Not sure if that is a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1482710683 From pminborg at openjdk.org Thu Feb 8 10:58:05 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Feb 2024 10:58:05 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: > This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. > > There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. > > Passes tier1, 2, and 3 tests. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Use existing UNSAFE static variable - Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17647/files - new: https://git.openjdk.org/jdk/pull/17647/files/21fcd8cf..27b8186a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17647/head:pull/17647 PR: https://git.openjdk.org/jdk/pull/17647 From pminborg at openjdk.org Thu Feb 8 12:03:02 2024 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Feb 2024 12:03:02 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:02:45 GMT, Aleksey Shipilev wrote: >> The CAS operation establishes a happens-before relation between the CAS operation itself and any following operations (such as `freeMemory()`). Also, only one thread will succeed in changing the value from zero to one. > > CAS block provides mutual exclusion here, as in, only one thread would ever execute the `freeMemory`/`unreserveMemory` block, which also does not modify any of the fields here. The only (?) thing we might be concerned with is that while one thread is running in the block, another thread would come and bypass the block. If anything relies on memory being actually freed after we exit `run()`, it might subtly misbehave -- accounting code, maybe? I guess a safer way to do this would be acquiring a lock, and checking `invoked` while holding it? Not sure if that is a problem. The behavior in this PR is now like the intended behavior in Java 21 (and before) but thread-safe. So, by induction, this should be as safe or safer as we had in <= 21. Adding blocking might introduce other problems in a multi-threaded environment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1482855731 From ihse at openjdk.org Thu Feb 8 13:42:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 13:42:07 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Once more, remove AIX dirent64 et al defines > > And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. > The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of *all* AIX 64-bit redefines, and then I'll (probably) do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934144258 From jkern at openjdk.org Thu Feb 8 14:50:08 2024 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 8 Feb 2024 14:50:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Once more, remove AIX dirent64 et al defines > > And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. > The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. Same as `statvfs`. Only the file system ID field is smaller. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934275624 From alanb at openjdk.org Thu Feb 8 15:33:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Feb 2024 15:33:04 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import There is no explicit free for direct buffers (or unmap for mapped buffers) and the Cleaner action to free/unmap will only be run once in response to reference processing. The only scenario that I can come up is using Unsafe.invokeCleaner where it looks like we might be missing a RF to keep the DBB alive. I will look further to see if I can see anything else. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1934374929 From ihse at openjdk.org Thu Feb 8 18:20:16 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 Feb 2024 18:20:16 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines And the smaller file system ID is not a problem, I guess? Do you want me to remove the redefines? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1934691860 From msheppar at openjdk.org Fri Feb 9 11:18:02 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 9 Feb 2024 11:18:02 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 12:00:44 GMT, Per Minborg wrote: >> CAS block provides mutual exclusion here, as in, only one thread would ever execute the `freeMemory`/`unreserveMemory` block, which also does not modify any of the fields here. The only (?) thing we might be concerned with is that while one thread is running in the block, another thread would come and bypass the block. If anything relies on memory being actually freed after we exit `run()`, it might subtly misbehave -- accounting code, maybe? I guess a safer way to do this would be acquiring a lock, and checking `invoked` while holding it? Not sure if that is a problem. > > The behavior in this PR is now like the intended behavior in Java 21 (and before) but thread-safe. So, by induction, this should be as safe or safer as we had in <= 21. Adding blocking might introduce other problems in a multi-threaded environment. thanks for the replies, so all invocations lead to Atomic::cmpxchg, where some magic happens....I didn't realise that AtomicInteger is basically a wrapper around what has been added to Deallocator ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1484181728 From alanb at openjdk.org Fri Feb 9 11:27:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Feb 2024 11:27:53 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import Just to add that I don't think Unsafe.invokeCleaner racing with the Cleaner is an issue. The clean method is specified to specified to invoke the cleaning action at most once, and the PhamtomCleanable.clean method appears to be correct. I wonder if @msheppar could re-phrase JDK-8324972 to more clearly explain why there is perceived issue issue. Note that I'm not opposed to making the cleaner action idempotent, I'm just trying to see how it possible for it to run more than once. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1935753766 From alanb at openjdk.org Fri Feb 9 11:41:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Feb 2024 11:41:06 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Once more, remove AIX dirent64 et al defines I can't comment on AIX but the changes look okay overall. I assume you'll bump the copyright header date on all the updated files before integrating. src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 257: > 255: static int fstatat_wrapper(int dfd, const char *path, > 256: struct stat *statbuf, int flag) > 257: { Minor nit - you can probably fix the align after the edit or collapse it into one line. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17538#pullrequestreview-1872182776 PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion_r1484203284 From bpb at openjdk.org Fri Feb 9 20:00:17 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 Feb 2024 20:00:17 GMT Subject: RFR: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size Message-ID: In `FileChannelImpl.transferTo`, do not clamp the number of bytes to transfer to the number remaining in the source `FileChannel` unless the size of the source is positive. When clamping, do not use the strict inequality `remaining > 0`, but rather allow clamping to zero. ------------- Commit messages: - 8325382: (fc) FileChannel.transferTo throws IOException when position equals size Changes: https://git.openjdk.org/jdk/pull/17796/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17796&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325382 Stats: 46 lines in 2 files changed: 32 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17796/head:pull/17796 PR: https://git.openjdk.org/jdk/pull/17796 From alanb at openjdk.org Sat Feb 10 16:09:03 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Feb 2024 16:09:03 GMT Subject: RFR: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 19:55:15 GMT, Brian Burkhalter wrote: > In `FileChannelImpl.transferTo`, do not clamp the number of bytes to transfer to the number remaining in the source `FileChannel` unless the size of the source is positive. When clamping, do not use the strict inequality `remaining > 0`, but rather allow clamping to zero. test/jdk/java/nio/channels/FileChannel/Transfer.java line 182: > 180: // FileChannelImpl.MAPPED_TRANSFER_THRESHOLD which is > 181: // currently 16384 > 182: chSource.transferTo(length, 16385, chTarget); "transferToTrusted" hints that this method will test a trusted target but it's actually a very specific test that doesn't test all trusted scenarios, and doesn't even check the return from transferTo. So I think this one is really a regression test that checks that it doesn't throw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17796#discussion_r1485183491 From msheppar at openjdk.org Sun Feb 11 14:05:02 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Sun, 11 Feb 2024 14:05:02 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import https://bugs.openjdk.org/browse/JDK-8316337 made a change advocating thread safety. That change had a flaw, incorrectly viewing Unsafe.freeMemory as idempotent, and as such is not thread safe, nor is it safe to multiple sequential invocation of the run method. The logic in the original incarnation of the run method, protected against multiple invocations (sequential or concurrent), and in particular multiple invocation of the lower level native free (memory) function, encapsulated in the Unsafe.freeMemory abstraction. The issue is raised to re-instate those semantics - idempotency, and additionally thread safety. The raised issue is about correct behaviour in the context of multiple concurrent and sequential access, regardless of whether there is the possibility of one thread or multiple threads. Per's retitle of the issue is a good one, appropriately elaborating the semantics of the change ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1937763194 From alanb at openjdk.org Mon Feb 12 07:15:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Feb 2024 07:15:04 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Sun, 11 Feb 2024 14:01:58 GMT, Mark Sheppard wrote: > https://bugs.openjdk.org/browse/JDK-8316337 made a change advocating thread safety. That change had a flaw, incorrectly viewing Unsafe.freeMemory as idempotent, and as such is not thread safe, nor is it safe to multiple sequential invocation of the run method. The comments added to JDK-8316337 aren't very clear. Would it be possible to outline the scenario that leads to the cleaning action be run more than once? I'm trying to see if there is a bug in the cleaner that explains this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1938152288 From ihse at openjdk.org Mon Feb 12 08:01:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:01:23 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge branch 'master' into jdk-FOB64 - Fix indentation - Once more, remove AIX dirent64 et al defines - Also fix fstatvfs on AIX - Redefine statvfs as statvfs64 on AIX - Add kludge to BufferedRenderPipe.c for AIX - Merge branch 'master' into jdk-FOB64 - Remove all system includes from debug_util.h - Merge branch 'master' into jdk-FOB64 - Move #include out of debug_util.h - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b ------------- Changes: https://git.openjdk.org/jdk/pull/17538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10 Stats: 284 lines in 29 files changed: 23 ins; 144 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 12 08:09:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:34 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v12] In-Reply-To: References: Message-ID: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17538/files - new: https://git.openjdk.org/jdk/pull/17538/files/caccbf9b..7f673ef6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17538&range=10-11 Stats: 26 lines in 26 files changed: 0 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/17538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17538/head:pull/17538 PR: https://git.openjdk.org/jdk/pull/17538 From ihse at openjdk.org Mon Feb 12 08:09:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:34 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote: >> And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. >> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > >> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. > > Same as `statvfs`. Only the file system ID field is smaller. @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938201250 From duke at openjdk.org Mon Feb 12 08:09:36 2024 From: duke at openjdk.org (Sam James) Date: Mon, 12 Feb 2024 08:09:36 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v11] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 08:01:23 GMT, Magnus Ihse Bursie wrote: >> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge branch 'master' into jdk-FOB64 > - Fix indentation > - Once more, remove AIX dirent64 et al defines > - Also fix fstatvfs on AIX > - Redefine statvfs as statvfs64 on AIX > - Add kludge to BufferedRenderPipe.c for AIX > - Merge branch 'master' into jdk-FOB64 > - Remove all system includes from debug_util.h > - Merge branch 'master' into jdk-FOB64 > - Move #include out of debug_util.h > - ... and 5 more: https://git.openjdk.org/jdk/compare/efa071dd...caccbf9b Thank you again for this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938202537 From ihse at openjdk.org Mon Feb 12 08:09:36 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 12 Feb 2024 08:09:36 GMT Subject: Integrated: 8324539: Do not use LFS64 symbols in JDK libs In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote: > Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK native libraries. This pull request has now been integrated. Changeset: e5cb78cc Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888 Stats: 310 lines in 29 files changed: 23 ins; 144 del; 143 mod 8324539: Do not use LFS64 symbols in JDK libs Reviewed-by: jwaters, erikj, mbaesken, alanb ------------- PR: https://git.openjdk.org/jdk/pull/17538 From jkern at openjdk.org Mon Feb 12 09:26:14 2024 From: jkern at openjdk.org (Joachim Kern) Date: Mon, 12 Feb 2024 09:26:14 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs [v10] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote: >> And also `#define statvfs statvfs64` is not necessary with the same explanation as for the `opendir` defines above -- sorry again. >> The very only difference between statvfs and statvfs64 is that the filesystem ID field in statvfs has a width of 8 Bytes, while in statvfs64 it has a width of 16 Bytes. > >> @JoKern65 So what about `#define fstatvfs fstatvfs64`? Is that still needed? If so, I could not be bothered to make another change. Otherwise, we can get rid of _all_ AIX 64-bit redefines, and then I'll (probably) do it. > > Same as `statvfs`. Only the file system ID field is smaller. > @JoKern65 @MBaesken I did not receive any reply about what to do with `fstatvfs`, so I decided to keep the last verified change for AIX. If you want to clean this up, then please do so, but at that time it will be an AIX-only patch. @magicus I have to reach out to IBM asking if the different size of the 'filesystem ID' field in statvfs makes an important difference. If not, I will remove the defines in an AIX-only patch. Thanks a lot for your effort. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1938300228 From msheppar at openjdk.org Mon Feb 12 09:50:57 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 12 Feb 2024 09:50:57 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import Is the Deallocator abstraction designed to be thread safe as advocated in https://bugs.openjdk.org/browse/JDK-8316337 ? Is it correct and proper design, hence good practice, as per the original logic, that Deallocator guard against improper release of its encapsulated native memory more than once? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1938337935 From alanb at openjdk.org Mon Feb 12 10:14:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Feb 2024 10:14:04 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 09:48:15 GMT, Mark Sheppard wrote: > Is the Deallocator abstraction designed to be thread safe as advocated in https://bugs.openjdk.org/browse/JDK-8316337 ? Is it correct and proper design, hence good practice, as per the original logic, that Deallocator guard against improper release of its encapsulated native memory more than once? Deallocator is a function that is intended to be run at most once. Mostly it will be called from the Cleaner thread but there is backdoor with Unsafe.invokeCleaner so it may be run by some other thread. Cleaner is designed, specified, and implemented, to invoke the cleaning action at most once, so Deallocator.run should run at most once. If there is a scenario where Deallocator.run can be run more than once then it is serious bug. I'm not opposed to make it idempotent but I'm concerned this is masking an issue elsewhere. If you have identified a scenario where it can be run more than once then it would be useful to get an outline so it can be studied. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1938378881 From bpb at openjdk.org Mon Feb 12 20:03:06 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Feb 2024 20:03:06 GMT Subject: RFR: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size [v2] In-Reply-To: References: Message-ID: > In `FileChannelImpl.transferTo`, do not clamp the number of bytes to transfer to the number remaining in the source `FileChannel` unless the size of the source is positive. When clamping, do not use the strict inequality `remaining > 0`, but rather allow clamping to zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8325382: Change sub-test name and check return ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17796/files - new: https://git.openjdk.org/jdk/pull/17796/files/40370a4f..ecd01954 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17796&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17796&range=00-01 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17796.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17796/head:pull/17796 PR: https://git.openjdk.org/jdk/pull/17796 From bpb at openjdk.org Mon Feb 12 20:03:06 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Feb 2024 20:03:06 GMT Subject: RFR: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size [v2] In-Reply-To: References: Message-ID: On Sat, 10 Feb 2024 16:06:35 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8325382: Change sub-test name and check return > > test/jdk/java/nio/channels/FileChannel/Transfer.java line 182: > >> 180: // FileChannelImpl.MAPPED_TRANSFER_THRESHOLD which is >> 181: // currently 16384 >> 182: chSource.transferTo(length, 16385, chTarget); > > "transferToTrusted" hints that this method will test a trusted target but it's actually a very specific test that doesn't test all trusted scenarios, and doesn't even check the return from transferTo. So I think this one is really a regression test that checks that it doesn't throw. Attempted to fix in ecd01954da61240c20143bba5348c7cba4d1a2f4. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17796#discussion_r1486705982 From alanb at openjdk.org Mon Feb 12 20:50:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Feb 2024 20:50:53 GMT Subject: RFR: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size [v2] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 20:03:06 GMT, Brian Burkhalter wrote: >> In `FileChannelImpl.transferTo`, do not clamp the number of bytes to transfer to the number remaining in the source `FileChannel` unless the size of the source is positive. When clamping, do not use the strict inequality `remaining > 0`, but rather allow clamping to zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8325382: Change sub-test name and check return Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17796#pullrequestreview-1876248899 From rriggs at openjdk.org Mon Feb 12 21:33:12 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Feb 2024 21:33:12 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Message-ID: Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. Added tests for UTF16 strings and a regression test. ------------- Commit messages: - 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Changes: https://git.openjdk.org/jdk/pull/17817/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17817&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325590 Stats: 24 lines in 2 files changed: 18 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17817/head:pull/17817 PR: https://git.openjdk.org/jdk/pull/17817 From alanb at openjdk.org Tue Feb 13 07:24:03 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 07:24:03 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote: > Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. test/jdk/java/nio/file/Files/ReadWriteString.java line 322: > 320: } > 321: assertEquals(actual, original, "Round trip string mismatch with multi-byte encoding"); > 322: } The update to newStringNoRepl1 looks fine. The added test is very different to the tests in this source file. We really need to expand the test to exercise a lot more charsets and input cases. It's okay to have a targeted test for now but needs to be renamed to be consistent with the other tests. Also the other tests use testFiles as the file paths rather than putting files in /tmp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17817#discussion_r1487326652 From rriggs at openjdk.org Tue Feb 13 12:47:26 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 12:47:26 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2] In-Reply-To: References: Message-ID: > Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Test Files.readString with multiple charsets Cleanup regression test to match style of other tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17817/files - new: https://git.openjdk.org/jdk/pull/17817/files/45ed4e19..39403b00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17817&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17817&range=00-01 Stats: 21 lines in 1 file changed: 15 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17817.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17817/head:pull/17817 PR: https://git.openjdk.org/jdk/pull/17817 From rriggs at openjdk.org Tue Feb 13 12:47:27 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 12:47:27 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 07:21:01 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Test Files.readString with multiple charsets >> Cleanup regression test to match style of other tests > > test/jdk/java/nio/file/Files/ReadWriteString.java line 322: > >> 320: } >> 321: assertEquals(actual, original, "Round trip string mismatch with multi-byte encoding"); >> 322: } > > The update to newStringNoRepl1 looks fine. > > The added test is very different to the tests in this source file. We really need to expand the test to exercise a lot more charsets and input cases. It's okay to have a targeted test for now but needs to be renamed to be consistent with the other tests. Also the other tests use testFiles as the file paths rather than putting files in /tmp. The UTF-16 charset is added to the existing `readString` test. Additional charsets can be added, most will exercise the same code path in newStringNoRepl1 that uses a CharsetDecoder for all charsets other than UTF-8, ASCII, or ISO-8859-1. The additional individual test is taken from the bug report and is not strictly necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17817#discussion_r1487787125 From mbaesken at openjdk.org Tue Feb 13 13:58:11 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Feb 2024 13:58:11 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case Message-ID: In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java java.lang.RuntimeException: wrong username at SocketOptions.testPeerCred(SocketOptions.java:75) at SocketOptions.main(SocketOptions.java:52) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1583) It would be better to see the compared values (user name data we compare) and get them in the exception output. ------------- Commit messages: - JDK-8325743 Changes: https://git.openjdk.org/jdk/pull/17829/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17829&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325743 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17829/head:pull/17829 PR: https://git.openjdk.org/jdk/pull/17829 From jvernee at openjdk.org Tue Feb 13 14:18:23 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 13 Feb 2024 14:18:23 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v3] In-Reply-To: References: Message-ID: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into AlignedOffset - Merge branch 'master' into AlignedOffset - Add api note pointing to alternatives for client that require non-plain access - simplify spec for alignmentOffset and alignedSlice - Merge note about misaligned access in byteBufferViewVarHandle - updated alignedSlice implNote as well - updated alignedOffset implNote - Use ISE for bbvvh instead of UOE - restore some tests for direct buffers - fix BAVV and BBVV impl and tests - ... and 2 more: https://git.openjdk.org/jdk/compare/a2273ed0...281deaa5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16681/files - new: https://git.openjdk.org/jdk/pull/16681/files/eccf4f41..281deaa5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16681&range=01-02 Stats: 14804 lines in 723 files changed: 8780 ins; 2698 del; 3326 mod Patch: https://git.openjdk.org/jdk/pull/16681.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16681/head:pull/16681 PR: https://git.openjdk.org/jdk/pull/16681 From jvernee at openjdk.org Tue Feb 13 14:18:27 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 13 Feb 2024 14:18:27 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong [v2] In-Reply-To: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> References: <7BH7MA_XWtqbGekVB83r9KMCYIq2P1QXeMX25QmqvTU=.edb35293-fa11-4d7f-945d-9ec0ce0e2a31@github.com> Message-ID: On Thu, 1 Feb 2024 20:10:29 GMT, Jorn Vernee wrote: >> See the JBS issue for an extended problem description. >> >> This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). >> >> - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. >> >> - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. >> >> - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: >> >> >> * @throws UnsupportedOperationException >> * If the native platform does not guarantee stable alignment offset >> * values for the given unit size when managing the memory regions >> * of buffers of the same kind as this buffer (direct or >> * non-direct). For example, if garbage collection would... > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' into AlignedOffset > - Add api note pointing to alternatives for client that require non-plain access > - simplify spec for alignmentOffset and alignedSlice > - Merge note about misaligned access in byteBufferViewVarHandle > - updated alignedSlice implNote as well > - updated alignedOffset implNote > - Use ISE for bbvvh instead of UOE > - restore some tests for direct buffers > - fix BAVV and BBVV impl and tests > - regen test files > - ... and 1 more: https://git.openjdk.org/jdk/compare/1d01cf48...eccf4f41 I'll do one more batch of testing (after merging with the latest master) and then integrate ------------- PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1941613924 From dfuchs at openjdk.org Tue Feb 13 14:28:02 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 13 Feb 2024 14:28:02 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 13:54:12 GMT, Matthias Baesken wrote: > In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java > > java.lang.RuntimeException: wrong username > at SocketOptions.testPeerCred(SocketOptions.java:75) > at SocketOptions.main(SocketOptions.java:52) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > It would be better to see the compared values (user name data we compare) and get them in the exception output. Since this is a test the proposed changes look reasonable to me. @Michael-Mc-Mahon may have more comments. You may want to consider adding a line break to avoid long lines. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17829#pullrequestreview-1878089151 From alanb at openjdk.org Tue Feb 13 14:45:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 14:45:58 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 13:54:12 GMT, Matthias Baesken wrote: > In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java > > java.lang.RuntimeException: wrong username > at SocketOptions.testPeerCred(SocketOptions.java:75) > at SocketOptions.main(SocketOptions.java:52) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > It would be better to see the compared values (user name data we compare) and get them in the exception output. test/jdk/java/nio/channels/unixdomain/SocketOptions.java line 76: > 74: if (!s1.equals(s2)) { > 75: throw new RuntimeException("wrong username, we got " + s1 + " but property user.name is " + s2); > 76: } It might be better to use "expected" and "actual" instead of "we got" :-) I assume you'll bump the copyright header before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17829#discussion_r1487987709 From alanb at openjdk.org Tue Feb 13 14:47:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 14:47:12 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs wrote: >> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. >> Added tests for UTF16 strings and a regression test. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Test Files.readString with multiple charsets > Cleanup regression test to match style of other tests Thanks for update, looks good. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17817#pullrequestreview-1878145643 From redestad at openjdk.org Tue Feb 13 14:53:53 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 13 Feb 2024 14:53:53 GMT Subject: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 12:47:26 GMT, Roger Riggs wrote: >> Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. >> Added tests for UTF16 strings and a regression test. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Test Files.readString with multiple charsets > Cleanup regression test to match style of other tests Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17817#pullrequestreview-1878164294 From mbaesken at openjdk.org Tue Feb 13 14:59:13 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Feb 2024 14:59:13 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case [v2] In-Reply-To: References: Message-ID: > In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java > > java.lang.RuntimeException: wrong username > at SocketOptions.testPeerCred(SocketOptions.java:75) > at SocketOptions.main(SocketOptions.java:52) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > It would be better to see the compared values (user name data we compare) and get them in the exception output. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust output and header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17829/files - new: https://git.openjdk.org/jdk/pull/17829/files/19e7a9b6..f7366970 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17829&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17829&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17829.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17829/head:pull/17829 PR: https://git.openjdk.org/jdk/pull/17829 From mbaesken at openjdk.org Tue Feb 13 14:59:13 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Feb 2024 14:59:13 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 14:43:30 GMT, Alan Bateman wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust output and header > > test/jdk/java/nio/channels/unixdomain/SocketOptions.java line 76: > >> 74: if (!s1.equals(s2)) { >> 75: throw new RuntimeException("wrong username, we got " + s1 + " but property user.name is " + s2); >> 76: } > > It might be better to use "expected" and "actual" instead of "we got" :-) > > I assume you'll bump the copyright header before integrating. Thanks, I adjusted the header and also the output. Added a line break. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17829#discussion_r1488014167 From mbaesken at openjdk.org Tue Feb 13 15:08:09 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 13 Feb 2024 15:08:09 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 14:25:03 GMT, Daniel Fuchs wrote: > Since this is a test the proposed changes look reasonable to me. @Michael-Mc-Mahon may have more comments. You may want to consider adding a line break to avoid long lines. Btw. in some other places we happily print the user name/id in the exception (but indeed this is test code so it should be no issue). https://github.com/openjdk/jdk/blame/master/src/java.base/unix/classes/sun/nio/fs/UnixUserPrincipals.java#L144 leads to (test injdk21u-dev), the user name seems no we messed up because of the bad LDAP we had on the test system, that's why only the id shows up in the exception java.io.IOException: 3199: at java.base/sun.nio.fs.UnixUserPrincipals.lookupName(UnixUserPrincipals.java:145) at java.base/sun.nio.fs.UnixUserPrincipals.lookupUser(UnixUserPrincipals.java:167) at java.base/sun.nio.fs.UnixFileSystem$LookupService$1.lookupPrincipalByName(UnixFileSystem.java:361) at CheckPermissions.main(CheckPermissions.java:775) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1583) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17829#issuecomment-1941715306 From rriggs at openjdk.org Tue Feb 13 15:20:08 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 15:20:08 GMT Subject: Integrated: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: <12jt0yObhaZkFCwcAcXE-BiCrfwseiVubjAq2BynSd8=.8b6267fe-6bd8-41da-b643-e5b5159c10fd@github.com> On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote: > Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. This pull request has now been integrated. Changeset: 13d9e8ff Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/13d9e8ff38536287b82c54bb63bd2d20f65615dc Stats: 39 lines in 2 files changed: 32 ins; 2 del; 5 mod 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Reviewed-by: alanb, redestad ------------- PR: https://git.openjdk.org/jdk/pull/17817 From bpb at openjdk.org Tue Feb 13 15:56:08 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Feb 2024 15:56:08 GMT Subject: Integrated: 8325382: (fc) FileChannel.transferTo throws IOException when position equals size In-Reply-To: References: Message-ID: On Fri, 9 Feb 2024 19:55:15 GMT, Brian Burkhalter wrote: > In `FileChannelImpl.transferTo`, do not clamp the number of bytes to transfer to the number remaining in the source `FileChannel` unless the size of the source is positive. When clamping, do not use the strict inequality `remaining > 0`, but rather allow clamping to zero. This pull request has now been integrated. Changeset: 6b7c9718 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/6b7c9718d68f30f47a163042d6e205945b9ff365 Stats: 50 lines in 2 files changed: 36 ins; 9 del; 5 mod 8325382: (fc) FileChannel.transferTo throws IOException when position equals size Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17796 From alanb at openjdk.org Tue Feb 13 15:56:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 15:56:06 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 14:59:13 GMT, Matthias Baesken wrote: >> In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java >> >> java.lang.RuntimeException: wrong username >> at SocketOptions.testPeerCred(SocketOptions.java:75) >> at SocketOptions.main(SocketOptions.java:52) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1583) >> >> It would be better to see the compared values (user name data we compare) and get them in the exception output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust output and header Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17829#pullrequestreview-1878336840 From rriggs at openjdk.org Tue Feb 13 16:02:27 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 16:02:27 GMT Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Message-ID: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 ------------- Commit messages: - Backport 13d9e8ff38536287b82c54bb63bd2d20f65615dc Changes: https://git.openjdk.org/jdk22/pull/110/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325590 Stats: 39 lines in 2 files changed: 32 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk22/pull/110.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/110/head:pull/110 PR: https://git.openjdk.org/jdk22/pull/110 From redestad at openjdk.org Tue Feb 13 16:13:12 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 13 Feb 2024 16:13:12 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF Message-ID: Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream Testing: tier1-3 ------------- Commit messages: - Merge branch 'master' into io_utf8_fastpath - Reduce cost for small Strings in DataInputStream - Optimize away StringBuilder for strings smaller than CHAR_BUF_SIZE chars, add more micros, minor improvements - Sync up DataInputStreamTest to make results comparable with ObjectInputStreamTest, fix a buffer overrun issue in ObjectInputStream - Remove stray code - Clean up DataInputStream.readUTF/readUTFChars - Use ISO-8859-1 to avoid back-to-back countPositives scans - Rearrange JLA - Add ASCII fast-path to Data-/ObjectInputStream.readUTF Changes: https://git.openjdk.org/jdk/pull/17734/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325340 Stats: 413 lines in 4 files changed: 375 ins; 15 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Tue Feb 13 16:13:12 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 13 Feb 2024 16:13:12 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Benchmark numbers M1 MacBook: Name Cnt Base Error Test Error Unit Change DataInputStreamTest.readUTFAsciiLarge 20 1,517 ? 0,018 1,052 ? 0,014 us/op 1,44x (p = 0,000*) DataInputStreamTest.readUTFAsciiMixed 20 1,391 ? 0,012 1,034 ? 0,021 us/op 1,34x (p = 0,000*) DataInputStreamTest.readUTFAsciiSmall 20 1,017 ? 0,019 1,007 ? 0,010 us/op 1,01x (p = 0,085 ) DataInputStreamTest.readUTFLarge 20 2,109 ? 0,032 2,025 ? 0,028 us/op 1,04x (p = 0,000*) DataInputStreamTest.readUTFMixed 20 1,651 ? 0,085 1,615 ? 0,025 us/op 1,02x (p = 0,124 ) DataInputStreamTest.readUTFSmall 20 1,020 ? 0,015 1,021 ? 0,014 us/op 1,00x (p = 0,773 ) ObjectInputStreamTest.readUTFAsciiLarge 15 3,094 ? 0,064 1,070 ? 0,018 us/op 2,89x (p = 0,000*) ObjectInputStreamTest.readUTFAsciiMixed 15 2,670 ? 0,062 0,779 ? 0,024 us/op 3,43x (p = 0,000*) ObjectInputStreamTest.readUTFAsciiSmall 15 1,138 ? 0,037 0,594 ? 0,026 us/op 1,92x (p = 0,000*) ObjectInputStreamTest.readUTFLarge 15 4,714 ? 0,049 3,040 ? 0,023 us/op 1,55x (p = 0,000*) ObjectInputStreamTest.readUTFMixed 15 2,952 ? 0,032 2,358 ? 0,024 us/op 1,25x (p = 0,000*) ObjectInputStreamTest.readUTFSmall 15 1,544 ? 0,169 1,259 ? 0,055 us/op 1,23x (p = 0,000*) * = significant ``` Intel(R) Xeon(R) Platinum 8358 CPU @ 2.60GHz, Linux: ``` Name Cnt Base Error Test Error Unit Change DataInputStreamTest.readUTFAsciiLarge 20 2.827 ? 0.006 2.098 ? 0.016 us/op 1.35x (p = 0.000*) DataInputStreamTest.readUTFAsciiMixed 20 2.453 ? 0.009 2.071 ? 0.010 us/op 1.18x (p = 0.000*) DataInputStreamTest.readUTFAsciiSmall 20 1.957 ? 0.005 2.052 ? 0.015 us/op 0.95x (p = 0.000*) DataInputStreamTest.readUTFLarge 20 4.339 ? 0.038 4.057 ? 0.017 us/op 1.07x (p = 0.000*) DataInputStreamTest.readUTFMixed 20 3.494 ? 0.007 3.387 ? 0.042 us/op 1.03x (p = 0.000*) DataInputStreamTest.readUTFSmall 20 2.257 ? 0.009 2.309 ? 0.016 us/op 0.98x (p = 0.000*) ObjectInputStreamTest.readUTFAsciiLarge 15 5.056 ? 0.028 1.827 ? 0.021 us/op 2.77x (p = 0.000*) ObjectInputStreamTest.readUTFAsciiMixed 15 3.492 ? 0.107 1.221 ? 0.011 us/op 2.86x (p = 0.000*) ObjectInputStreamTest.readUTFAsciiSmall 15 1.651 ? 0.014 0.976 ? 0.018 us/op 1.69x (p = 0.000*) ObjectInputStreamTest.readUTFLarge 15 9.741 ? 0.034 6.049 ? 0.039 us/op 1.61x (p = 0.000*) ObjectInputStreamTest.readUTFMixed 15 5.786 ? 0.082 4.220 ? 0.008 us/op 1.37x (p = 0.000*) ObjectInputStreamTest.readUTFSmall 15 2.219 ? 0.075 1.405 ? 0.013 us/op 1.58x (p = 0.000*) * = significant For the `Small` variants of the `DataInputStream` the optimization doesn't pay off inputs less than 8 bytes. The added cost seen here is due the increased code complexity and an added branch, without the `utflen > 7` checks the `readUTFSmall` (slow-path test) would score 0.6-0.7x which was unacceptable. For the `ObjectInputStream` case the fast-path additionally helps avoid the need for a `StringBuilder` if the byte length of the UTF record fits in the shared `char[]`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1930221329 From liach at openjdk.org Tue Feb 13 16:13:12 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 Feb 2024 16:13:12 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: > 3686: // avoid a redundant scan > 3687: String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1); > 3688: pos += (int)utflen; Suggestion: String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1); pos += ascii; Redundant casts src/java.base/share/classes/java/io/ObjectInputStream.java line 3746: > 3744: int avail = Math.min(end - pos, CHAR_BUF_SIZE); > 3745: // stop short of last char unless all of utf bytes in buffer > 3746: int stop = start + ((utflen > avail) ? avail - 2 : (int) utflen); Though reading LV instead of getfield is an improvement, we probably prefer to keep this patch cleaner. src/java.base/share/classes/java/nio/charset/Charset.java line 682: > 680: else > 681: defaultCharset = sun.nio.cs.UTF_8.INSTANCE; > 682: Charset.forName("UTF-8"); Redundant debug code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480387150 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480389129 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480391246 From redestad at openjdk.org Tue Feb 13 16:13:12 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 13 Feb 2024 16:13:12 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com> On Tue, 6 Feb 2024 18:40:20 GMT, Chen Liang wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: > >> 3686: // avoid a redundant scan >> 3687: String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1); >> 3688: pos += (int)utflen; > > Suggestion: > > String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1); > pos += ascii; > > Redundant casts I get warnings and build failures if I leave out those casts (`utflen` is a `long`) > src/java.base/share/classes/java/nio/charset/Charset.java line 682: > >> 680: else >> 681: defaultCharset = sun.nio.cs.UTF_8.INSTANCE; >> 682: Charset.forName("UTF-8"); > > Redundant debug code? Yes, accidentally included here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480406485 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480404260 From liach at openjdk.org Tue Feb 13 16:13:12 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 13 Feb 2024 16:13:12 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com> References: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com> Message-ID: <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com> On Tue, 6 Feb 2024 18:58:01 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/io/ObjectInputStream.java line 3688: >> >>> 3686: // avoid a redundant scan >>> 3687: String utf = new String(buf, pos, (int)utflen, StandardCharsets.ISO_8859_1); >>> 3688: pos += (int)utflen; >> >> Suggestion: >> >> String utf = new String(buf, pos, ascii, StandardCharsets.ISO_8859_1); >> pos += ascii; >> >> Redundant casts > > I get warnings and build failures if I leave out those casts (`utflen` is a `long`) Ah, I meant to use the equivalent local variable int ascii, the return value of countPositives, to avoid these casts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1480639568 From alanb at openjdk.org Tue Feb 13 16:14:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 16:14:04 GMT Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Marked as reviewed by alanb (Reviewer). This is for jdk22u, not jdk22 This is for jdk22u, not jdk22 ------------- PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878383225 PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878385355 Changes requested by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/110#pullrequestreview-1878386430 From kcr at openjdk.org Tue Feb 13 16:14:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 16:14:05 GMT Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 @RogerRiggs Since this is deferred out of JDK 22, you need to close this PR and open a new one against jdk22u. ------------- PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941908401 From kcr at openjdk.org Tue Feb 13 16:14:05 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 13 Feb 2024 16:14:05 GMT Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 16:09:04 GMT, Alan Bateman wrote: >> 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 > > This is for jdk22u, not jdk22 @AlanBateman You might want to unapprove this PR (go to "Files" and submit a review with "Request Changes") UPDATE: I see you already did. ------------- PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941917372 From rriggs at openjdk.org Tue Feb 13 16:18:08 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 16:18:08 GMT Subject: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 The backport was intended to be for jdk22u ------------- PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941927141 From rriggs at openjdk.org Tue Feb 13 16:18:08 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Feb 2024 16:18:08 GMT Subject: [jdk22] Withdrawn: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk22/pull/110 From bpb at openjdk.org Tue Feb 13 19:11:24 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Feb 2024 19:11:24 GMT Subject: RFR: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact Message-ID: Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. ------------- Commit messages: - 8316340: Missing {@inheritDoc} for exception in MappedByteBuffer::compact Changes: https://git.openjdk.org/jdk/pull/17835/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316340 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17835.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17835/head:pull/17835 PR: https://git.openjdk.org/jdk/pull/17835 From bpb at openjdk.org Tue Feb 13 19:11:24 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Feb 2024 19:11:24 GMT Subject: RFR: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 19:06:06 GMT, Brian Burkhalter wrote: > Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. The specifications of the other methods in the various `Buffer` classes which mutate the data do not appear to have omitted any other instance of `ReadOnlyBufferException`. It was verified manually that `MappedByteBuffer.compact` does in fact throw a `ReadOnlyBufferException` if the buffer is is not writable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17835#issuecomment-1942205693 From alanb at openjdk.org Tue Feb 13 20:13:02 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Feb 2024 20:13:02 GMT Subject: RFR: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 19:06:06 GMT, Brian Burkhalter wrote: > Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17835#pullrequestreview-1878824220 From iris at openjdk.org Tue Feb 13 21:29:04 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 13 Feb 2024 21:29:04 GMT Subject: RFR: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact In-Reply-To: References: Message-ID: <3EsIiINctEhpWXzijvwC-DdAHWTLsaaRTFH9G-YzS3I=.5d980ddf-b7ef-4dbb-bfe3-f21cf5261d4a@github.com> On Tue, 13 Feb 2024 19:06:06 GMT, Brian Burkhalter wrote: > Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17835#pullrequestreview-1878947256 From lancea at openjdk.org Tue Feb 13 21:33:03 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 13 Feb 2024 21:33:03 GMT Subject: RFR: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 19:06:06 GMT, Brian Burkhalter wrote: > Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17835#pullrequestreview-1878960423 From redestad at openjdk.org Tue Feb 13 21:36:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 13 Feb 2024 21:36:03 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com> References: <7YF7_pI-7BKuDGWGHOJMANhn7Avv3Kvnxr55dm4XZAc=.6937ce45-2d81-4dec-860c-992ec288386c@github.com> <7EY1lQA_fbDNsmt-JxKxElo9BvWxh9IlUDSE_h_qlT0=.cdd57ff6-9900-40ef-baa9-0f6392f7b54d@github.com> Message-ID: On Tue, 6 Feb 2024 23:01:07 GMT, Chen Liang wrote: >> I get warnings and build failures if I leave out those casts (`utflen` is a `long`) > > Ah, I meant to use the equivalent local variable int ascii, the return value of countPositives, to avoid these casts. Missed this comment, but ended up doing like you suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1488613636 From mbaesken at openjdk.org Wed Feb 14 08:33:59 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Feb 2024 08:33:59 GMT Subject: RFR: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case [v2] In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 14:59:13 GMT, Matthias Baesken wrote: >> In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java >> >> java.lang.RuntimeException: wrong username >> at SocketOptions.testPeerCred(SocketOptions.java:75) >> at SocketOptions.main(SocketOptions.java:52) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >> at java.base/java.lang.reflect.Method.invoke(Method.java:580) >> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) >> at java.base/java.lang.Thread.run(Thread.java:1583) >> >> It would be better to see the compared values (user name data we compare) and get them in the exception output. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust output and header Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17829#issuecomment-1943286455 From mbaesken at openjdk.org Wed Feb 14 08:34:00 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 14 Feb 2024 08:34:00 GMT Subject: Integrated: JDK-8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case In-Reply-To: References: Message-ID: On Tue, 13 Feb 2024 13:54:12 GMT, Matthias Baesken wrote: > In case of a bad running LDAP we got this output from test test/jdk/java/nio/channels/unixdomain/SocketOptions.java > > java.lang.RuntimeException: wrong username > at SocketOptions.testPeerCred(SocketOptions.java:75) > at SocketOptions.main(SocketOptions.java:52) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) > at java.base/java.lang.reflect.Method.invoke(Method.java:580) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1583) > > It would be better to see the compared values (user name data we compare) and get them in the exception output. This pull request has now been integrated. Changeset: d0039960 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d0039960c4fdaf7704d06e1233865ea2e27a5d39 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8325743: test/jdk/java/nio/channels/unixdomain/SocketOptions.java enhance user name output in error case Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/17829 From rgiulietti at openjdk.org Wed Feb 14 10:44:03 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 Feb 2024 10:44:03 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 src/java.base/share/classes/java/io/DataInputStream.java line 585: > 583: DataInputStream dis = null; > 584: if (in instanceof DataInputStream) { > 585: dis = (DataInputStream)in; I guess that not making use of `instanceof` pattern matching is to enable backporting before JDK 16? src/java.base/share/classes/java/io/DataInputStream.java line 604: > 602: // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant > 603: // scan > 604: return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1); Not sure this is correct. If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489261534 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489261783 From redestad at openjdk.org Wed Feb 14 11:32:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 14 Feb 2024 11:32:03 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> On Wed, 14 Feb 2024 10:41:17 GMT, Raffaello Giulietti wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > src/java.base/share/classes/java/io/DataInputStream.java line 604: > >> 602: // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant >> 603: // scan >> 604: return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1); > > Not sure this is correct. > If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros. While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489325376 From rgiulietti at openjdk.org Wed Feb 14 11:37:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 Feb 2024 11:37:54 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> References: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> Message-ID: On Wed, 14 Feb 2024 11:29:43 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/io/DataInputStream.java line 604: >> >>> 602: // For ASCII ISO-8859-1 is equivalent to UTF-8, while avoiding a redundant >>> 603: // scan >>> 604: return new String(bytearr, 0, utflen, StandardCharsets.ISO_8859_1); >> >> Not sure this is correct. >> If `bytearr` contains some `(byte)0`, that is, if `in` is malformed, this doesn't throw `UTFDataFormatException`, but it should: modified UTF-8 cannot contain zeros. > > While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold. Ah OK. I didn't check the current code, only the proposed one. Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489331002 From redestad at openjdk.org Wed Feb 14 14:32:55 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 14 Feb 2024 14:32:55 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> Message-ID: On Wed, 14 Feb 2024 11:35:10 GMT, Raffaello Giulietti wrote: >> While properly encoded modified UTF-8 strings won't have embedded zeros (`\u0000` will be encoded as `0xC0, 0x80`) the decoding routines in `DataInputStream` and `ObjectInputStream` allows them and does not throw an exception if an embedded zero is encountered. This PR does not change semantics here AFAICT. If you think we need to be stricter in these decoders that could be done as a separate RFE and I'll put this on hold. > > Ah OK. > > I didn't check the current code, only the proposed one. > Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either. The specification is somewhat ambiguous: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF() There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489564324 From jvernee at openjdk.org Wed Feb 14 14:34:12 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 14 Feb 2024 14:34:12 GMT Subject: Integrated: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... This pull request has now been integrated. Changeset: 9c852df6 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/9c852df6aa019f63d6fae733d7a73521b7151dd0 Stats: 5133 lines in 19 files changed: 612 ins; 3440 del; 1081 mod 8318966: Some methods make promises about Java array element alignment that are too strong Reviewed-by: psandoz, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/16681 From bpb at openjdk.org Wed Feb 14 16:02:06 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Feb 2024 16:02:06 GMT Subject: Integrated: 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact In-Reply-To: References: Message-ID: <3q_fxyNMOoQy76WJ1UQvd9DVD292q5PnmDKDykhwrkA=.44eb5c73-2d4e-415d-ba1c-0e3f95541fdf@github.com> On Tue, 13 Feb 2024 19:06:06 GMT, Brian Burkhalter wrote: > Explicitly add a throws clause for `ReadOnlyBufferException` to the specification of `MappedByteBuffer.compact`. This pull request has now been integrated. Changeset: f6e28510 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/f6e285103ad8c840c26e4611e16bb9bf3b2de90c Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact Reviewed-by: alanb, iris, lancea ------------- PR: https://git.openjdk.org/jdk/pull/17835 From bpb at openjdk.org Wed Feb 14 20:07:04 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Feb 2024 20:07:04 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 As there are no regression tests added by this request, I assume that existing tests must sufficiently cover this area. If so, however, the issue has no `noreg-` label. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1944507481 From bpb at openjdk.org Wed Feb 14 20:07:05 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Feb 2024 20:07:05 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 10:41:08 GMT, Raffaello Giulietti wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > src/java.base/share/classes/java/io/DataInputStream.java line 585: > >> 583: DataInputStream dis = null; >> 584: if (in instanceof DataInputStream) { >> 585: dis = (DataInputStream)in; > > I guess that not making use of `instanceof` pattern matching is to enable backporting before JDK 16? I have the same question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1489994945 From redestad at openjdk.org Wed Feb 14 22:12:15 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 14 Feb 2024 22:12:15 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v2] In-Reply-To: References: Message-ID: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Refactor to use a shared impl for slow-path mod-UTF8 decoding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/90a805bf..e6a8c312 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=00-01 Stats: 94 lines in 2 files changed: 13 ins; 46 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Wed Feb 14 23:32:17 2024 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 14 Feb 2024 23:32:17 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v3] In-Reply-To: References: Message-ID: <2_qXqLlAdhLofohkeDtG8DiInZG8tCiISprn6YtI5Cc=.768ae3b0-70df-481d-aab6-08d7651f4df6@github.com> > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert "Refactor to use a shared impl for slow-path mod-UTF8 decoding" This reverts commit e6a8c3120b7f9c96a66ba40c27f8352735cdb588. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/e6a8c312..5655826b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=01-02 Stats: 94 lines in 2 files changed: 46 ins; 13 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From alanb at openjdk.org Thu Feb 15 08:21:05 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Feb 2024 08:21:05 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 09:48:15 GMT, Mark Sheppard wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use existing UNSAFE static variable >> - Remove unused import > > Is the Deallocator abstraction designed to be thread safe as advocated in https://bugs.openjdk.org/browse/JDK-8316337 ? > Is it correct and proper design, hence good practice, as per the original logic, that Deallocator guard against improper release of its encapsulated native memory more than once? @msheppar Do you have any other information to add? I'm wondering if this issue should be closed as it seems to be passed on the assumption that the cleaning action runs more than once. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1945561495 From redestad at openjdk.org Thu Feb 15 10:30:20 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 15 Feb 2024 10:30:20 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v4] In-Reply-To: References: Message-ID: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert changes to DataInputStream ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/5655826b..3e712648 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=02-03 Stats: 50 lines in 1 file changed: 8 ins; 24 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Thu Feb 15 10:33:07 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 15 Feb 2024 10:33:07 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v5] In-Reply-To: References: Message-ID: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com> > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert spurious formatting changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/3e712648..ca2b09c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=03-04 Stats: 17 lines in 1 file changed: 0 ins; 7 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Thu Feb 15 10:38:06 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 15 Feb 2024 10:38:06 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v5] In-Reply-To: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com> References: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com> Message-ID: <4Yh-5DOHMZMWJVC21CZ5Ui9Pk9LYOO0vjs4c_0bFjoA=.ecb569ef-f2ee-47c9-8cc5-31940b2b2cd7@github.com> On Thu, 15 Feb 2024 10:33:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert spurious formatting changes After some deliberation I decided to back out the proposed changes to `DataInputStream`. It sees less of a speed-up in my tests thanks to an existing simple fast-path - and there are paths through the code that are not covered by these microbenchmarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1945796077 From redestad at openjdk.org Thu Feb 15 10:47:04 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 15 Feb 2024 10:47:04 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: On Wed, 14 Feb 2024 20:04:42 GMT, Brian Burkhalter wrote: > As there are no regression tests added by this request, I assume that existing tests must sufficiently cover this area. If so, however, the issue has no `noreg-` label. At least for `ObjectInputStream` there's a large and seemingly very thorough selection of often randomized tests that explicitly and implicitly exercises `readUTF`, including most of the tests in `java/io/Serializable`. `DataInputStream` tests seem less thorough, though that doesn't matter for this since I'm pulling out those changes. I added `noreg-perf` to the bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1945820085 From rgiulietti at openjdk.org Thu Feb 15 10:57:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 Feb 2024 10:57:54 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v5] In-Reply-To: References: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> Message-ID: On Wed, 14 Feb 2024 14:30:02 GMT, Claes Redestad wrote: >> Ah OK. >> >> I didn't check the current code, only the proposed one. >> Although the specification clearly states that the method should throw, if the current code does not throw on zeros, then it makes sense that the proposed one shouldn't either. > > The specification is somewhat ambiguous: > https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF() > > There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence. In fact, the implementations of `readUTF*()` in `DataInputStream` and `ObjectInputStream` are much more lenient than that. They also accept ASCII characters that are encoded with 2 bytes instead of 1. There's no check that the encoding is "minimal length". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490820923 From rgiulietti at openjdk.org Thu Feb 15 11:03:02 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 Feb 2024 11:03:02 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v5] In-Reply-To: References: <0ql4FUUK2bFwDWVXGrZwHic4nN5iyUIE4pZAMEQncIo=.b2b69c82-1bfb-4542-977b-32a582755f64@github.com> Message-ID: On Thu, 15 Feb 2024 10:55:38 GMT, Raffaello Giulietti wrote: >> The specification is somewhat ambiguous: >> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF() >> >> There's a sweeping `Throws UTFDataFormatException - if the bytes do not represent a valid modified UTF-8 encoding of a string` but also: `If the first byte of a group matches the bit pattern 0xxxxxxx (where x means "may be 0 or 1"), then the group consists of just that byte. The byte is zero-extended to form a character.` I think the latter gives some leeway on being lenient on embedded zeros, even if it's made clear elsewhere that valid encoders need to replace zeros with the `0xC0, 0x80` sequence. > > In fact, the implementations of `readUTF*()` in `DataInputStream` and `ObjectInputStream` are much more lenient than that. They also accept ASCII characters that are encoded with 2 bytes instead of 1. There's no check that the encoding is "minimal length". This is according to `DataInput` specification. So what `UTFDataFormatException` means is kind of ambiguous. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490826777 From msheppar at openjdk.org Thu Feb 15 11:59:06 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 15 Feb 2024 11:59:06 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Mon, 12 Feb 2024 09:48:15 GMT, Mark Sheppard wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use existing UNSAFE static variable >> - Remove unused import > > Is the Deallocator abstraction designed to be thread safe as advocated in https://bugs.openjdk.org/browse/JDK-8316337 ? > Is it correct and proper design, hence good practice, as per the original logic, that Deallocator guard against improper release of its encapsulated native memory more than once? > @msheppar Do you have any other information to add? I'm wondering if this issue should be closed as it seems to be passed on the assumption that the cleaning action runs more than once. I've nothing to add other than to re-iterate if https://bugs.openjdk.org/browse/JDK-8316337 is made based on thread safety, then it needs to take into account the idempotent release of the underlying native memory as per the original logic. Otherwise base on your assertions the https://bugs.openjdk.org/browse/JDK-8316337 was not required ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1945951126 From rgiulietti at openjdk.org Thu Feb 15 12:03:54 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 15 Feb 2024 12:03:54 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v5] In-Reply-To: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com> References: <8-ZU83v8i-p_Md_Qrx2qgqTJvwPq0sY691aD6dPSYJ8=.00c58942-6eab-4aef-8fbf-1d8b2702bf05@github.com> Message-ID: On Thu, 15 Feb 2024 10:33:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert spurious formatting changes src/java.base/share/classes/java/io/DataInputStream.java line 574: > 572: * @see java.io.DataInputStream#readUnsignedShort() > 573: */ > 574: public static final String readUTF(DataInput in) throws IOException { Suggestion: public static String readUTF(DataInput in) throws IOException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1490827814 From alanb at openjdk.org Thu Feb 15 12:15:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Feb 2024 12:15:53 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 11:55:55 GMT, Mark Sheppard wrote: > I've nothing to add other than to re-iterate if https://bugs.openjdk.org/browse/JDK-8316337 is made based on thread safety, then it needs to take into account the idempotent release of the underlying native memory as per the original logic. Otherwise base on your assertions the https://bugs.openjdk.org/browse/JDK-8316337 was not required JDK-8316337 was about visibility and safe publication, it didn't introduce a way for the cleaning action to run more than once. I think we can close 8324972 and this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1945977876 From msheppar at openjdk.org Thu Feb 15 12:32:04 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 15 Feb 2024 12:32:04 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 12:13:26 GMT, Alan Bateman wrote: > > I've nothing to add other than to re-iterate if https://bugs.openjdk.org/browse/JDK-8316337 is made based on thread safety, then it needs to take into account the idempotent release of the underlying native memory as per the original logic. Otherwise base on your assertions the https://bugs.openjdk.org/browse/JDK-8316337 was not required > > JDK-8316337 was about visibility and safe publication, it didn't introduce a way for the cleaning action to run more than once. I think we can close 8324972 and this PR. regardless, it was logically incorrect ! All that was needed for the original change was a re-entrant lock to protect the state, there was no need to change to a record. This change does the same guaranteeing visibility and safe publication, while guarding against errant concurrent execution, making the class semantically correct, robust and thread safe. Despite your assertions you can't guarantee that multiple threads won't be running through the Dealloactor, due to some erroneous behaviour and the original logic attempted to guard against this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1946003716 From redestad at openjdk.org Thu Feb 15 13:07:20 2024 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 15 Feb 2024 13:07:20 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v6] In-Reply-To: References: Message-ID: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/io/DataInputStream.java Co-authored-by: Raffaello Giulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/ca2b09c6..48902ad2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From eirbjo at openjdk.org Thu Feb 15 13:52:01 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:01 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line Message-ID: Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. ------------- Commit messages: - Update constant ZIP64_SIZE to be the sum of EXTRA_HEADER_SIZE and ZIP64_DATA_SIZE - Merge branch 'master' into loc-offset-zip64-sparse - Convert test from testng to junit - Merge branch 'master' into loc-offset-zip64-sparse - Add a third DEFLATED entry to the test ZIP. Look up CEN offset from END header instead of skipping LOC headers. Add asserts that verifies that the ZIP has the expected entries. - Merge branch 'master' into loc-offset-zip64-sparse - Add extra entry as a sanity check. Extract some constants for sizes and extract method makeOpaqueExtraField to allow some more in-depth commenting. Move extra field processing until after the LOC headers are written, such that this information only occurs in the CEN - APPNOTE.txt actually specifies an 'unknown' tag, let's use that instead of 0x42 - The Zip64 fields are all zero, we don't need to update them - Instead of making a big file to force Zip64, make a small file with a Zip64-formatted CEN header. - ... and 3 more: https://git.openjdk.org/jdk/compare/692c9f88...f845ff30 Changes: https://git.openjdk.org/jdk/pull/12979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303972 Stats: 209 lines in 2 files changed: 90 ins; 44 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/12979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12979/head:pull/12979 PR: https://git.openjdk.org/jdk/pull/12979 From lancea at openjdk.org Thu Feb 15 13:52:02 2024 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 15 Feb 2024 13:52:02 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. This test was leveraging a file created by info-zip intentionally so care needs to be taken to ensure that the zip that is being created is similar LOC and CEN output Thank you for your work here Eirik, I think we are close. I think I would include an additional entry in the zip just as an extra sanity check that we can navigate an additional entry It is also worth noting that the LOC will still contain an extra field with the unknown tag of 0x9902 while the CEN is being changed to use Zip64, 0x1 A few more minor comments below. I ran the current version of the test and it runs quickly on all platforms via mach5 Best Lance I think this looks good overall. Please see the comment below and then I can run the test one more time and you should be good to go test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 173: > 171: ByteBuffer buffer = ByteBuffer.wrap(zip64).order(ByteOrder.LITTLE_ENDIAN); > 172: buffer.putShort(UNKNOWN_TAG); // Opaque tag makes ZipEntry.setExtra ignore it > 173: buffer.putShort((short) (zip64.length - 2 * Short.BYTES)); // Data size The length of the zip64 extra field is going to be 28. I would suggest making this a bit clearer and adding a field/constant which is set to 28 for clarity to make it easier for those who might look at this code later test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 191: > 189: e.setExtra(zip64); > 190: > 191: zo.finish(); // Write out CEN and END records I might add one more entry after this one, perhaps with a compression method of DEFLATED test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 218: > 216: > 217: // Update the Zip64 field with the real tag > 218: buffer.putShort((short) 0x1); // Tag for Zip64 I would probably make 0x1 a constant like the unknown tag. It would be good to beef up the comment as the byte array written by ZipEntry::setExtra is set to the unknown tag for the Tag and the length is set to 28 which includes all of the Zip64 extra fields ------------- PR Review: https://git.openjdk.org/jdk/pull/12979#pullrequestreview-1335237759 PR Review: https://git.openjdk.org/jdk/pull/12979#pullrequestreview-1346294478 Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12979#pullrequestreview-1355345890 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1140464116 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1146677274 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1140457583 From eirbjo at openjdk.org Thu Feb 15 13:52:03 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:03 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 16:56:55 GMT, Lance Andersen wrote: > This test was leveraging a file created by info-zip intentionally so care needs to be taken to ensure that the zip that is being created is similar LOC and CEN output Yes, I just noticed that and currently looking into it. I think in particular it is sensitive to the ordering of the extended time stamp and the Zip64 entries, which is not the same as ZipOutputStream. > I think I would include an additional entry in the zip just as an extra sanity check that we can navigate an additional entry Added an additional entry as suggested and checked that is was navigated. > It is also worth noting that the LOC will still contain an extra field with the unknown tag of 0x9902 while the CEN is being changed to use Zip64, 0x1 This stray opaque extra field should not be any issue, but just in case, I moved the ZipFIle.setExtra until after the LOC is written, so now only the CEN will have the Zip64 extra field. > I think this looks good overall. Please see the comment below and then I can run the test one more time and you should be good to go This PR was approved by @LanceAndersen in March 2023, but for some reason it was never integrated. Most probably I was waiting for a final approval following the last review comments from Lance. The test was rewritten to JUnit in October 2023. The test is useful in that it covers an aspect sensitive to the order of ZIP64 extended fields which is produced by Info-ZIP, but which ZipOutputStream cannot produce. I think it would be good to bring this problem-listed test back to life and also make it platform independent. > The length of the zip64 extra field is going to be 28. I would suggest making this a bit clearer and adding a field/constant which is set to 28 for clarity to make it easier for those who might look at this code later I believe this should be well-described now between the constants and the `makeOpaqueExtraField` method. > test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 191: > >> 189: e.setExtra(zip64); >> 190: >> 191: zo.finish(); // Write out CEN and END records > > I might add one more entry after this one, perhaps with a compression method of DEFLATED I added a third DEFLATED entry, added asserts that ZipFile and ZipFileSystem finds the expected entries. The LOC traversal no longer works, so the CEN offset is now looked up from the EOC header instead. > I would probably make 0x1 a constant like the unknown tag. Extracted a constant with a comment. > It would be good to beef up the comment as the byte array written by ZipEntry::setExtra is set to the unknown tag for the Tag and the length is set to 28 which includes all of the Zip64 extra fields Opted to extract a method?to create the opaque extra field since that allows for more comments and declutters the calling method. I dropped the 'disk start' field since it is not relevant and we don't set the corresponding magic value. So the Zip64 data size is now 24 instead of 28. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1464103188 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1474300281 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1933880614 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1140626457 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1147207105 PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1140625661 From eirbjo at openjdk.org Thu Feb 15 13:52:03 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:03 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. Converting to draft while I investigate why the updated test does not actually catch the regression While it is possible to use a sparse file here, there is a problem that when ZipFileSystem reads inside a 'hole', it will skip ahead to the next data which turned out to be a LOC header. We could carefully select an entry size such that 0XFFFFFFFF does not not fall into in a hole, but that feels a bit too magic. Instead, I opted for creating a small ZIP file with a Zip64-formatted CEN. Since this issue is sensitive to ordering of extra fields, the 'extended timestamp' needs to come before the 'Zip64 extended information field'. The way I solve this is to add an opaque extra field, right sized for 'Zip64'. This uses a tag ID unknown to ZipEntry.setExtra, such that it will not be parsed as Zip64 but simply passed through. ZipOutputStream will output this after the extended timestamp. After the ZIP is produced, the Zip64 entry is updated with the correct tag. I have verified that this causes ZipFileSystem (before JDK-8255380) to attempt to read the LOC from 0xFFFFFFFF. With a small file size, this causes a slightly different error message because of the attempt to read beyond the end of the file. ----------System.out:(160/10450)---------- config TestLocOffsetFromZip64EF.setUp(): success test TestLocOffsetFromZip64EF.walkZipFSTest({}): failure java.util.zip.ZipException: loc: reading failed at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:3127) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2831) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.(ZipFileSystem.java:2767) at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:550) ``` While the symptom is slightly different, the cause is the same: ZipFileSystem tries to read the LOC at offset 0xFFFFFFFF because it has not read the Zip64 entry yet. I ran the latest version of the test against a reverted ZipFileSystem to confirmed that it still catches the regression it was made for. Something worth mentioning: This test currently does not check that the last modified time stamp is actually the one read from the LOC and not from the CEN. And there is a discrepancey here, `ZipFileSystem` reads it from the LOC, while `ZipFile` reads it from the CEN. We could test this by setting different last modified timestamps in the LOC and CEN and use assertEquals to verify that the expected time stamp is parsed. @LanceAndersen Do you think this is worth pursuing in this PR? I have a sketch ready, but I fear will clutter the test with too many concerns. Perhaps better to test in a separate test which could be independent from Zip64 and local header offset concerns? This comment is just to test if nio-dev is notified of updates in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1463991756 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1464380674 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1474303991 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1474308875 PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1943537773 From alanb at openjdk.org Thu Feb 15 13:52:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Feb 2024 13:52:04 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 136: > 134: // Make a ZIP with two entries > 135: try (FileOutputStream fileOutputStream = new FileOutputStream(new File(ZIP_FILE_NAME)); > 136: ZipOutputStream zo = new ZipOutputStream(new SparseOutputStream(fileOutputStream))) { Can you use FileChannel.open and specify SPARSE in the set of open options, I think that would make it clearer that the file is sparse and remove the need for SparseOutputStream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132548206 From jpai at openjdk.org Thu Feb 15 13:52:03 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Feb 2024 13:52:03 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. Hello Eirik, before integrating this I'll run this against a specific version of OS to verify that the test that is being removed from the problem listing does indeed work fine on that OS. Given that we no longer depend on a OS specific tool to generate the zip, I think it should work fine, but I'll do one run to be sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1943571291 From eirbjo at openjdk.org Thu Feb 15 13:52:04 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:04 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:48:40 GMT, Alan Bateman wrote: >> Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. >> >> Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). >> >> This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. >> >> Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. > > test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 136: > >> 134: // Make a ZIP with two entries >> 135: try (FileOutputStream fileOutputStream = new FileOutputStream(new File(ZIP_FILE_NAME)); >> 136: ZipOutputStream zo = new ZipOutputStream(new SparseOutputStream(fileOutputStream))) { > > Can you use FileChannel.open and specify SPARSE in the set of open options, I think that would make it clearer that the file is sparse and remove the need for SparseOutputStream. Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:), but that doesn't give me an OutputStream I can pass to ZipOutputStream? I could use Channels.newOutputStream, but that would not create holes in the sparse files? My current thinking is that we need the SparseOutputStream to detect that ZIpOutputStream is writing empty bytes and replace that with `channel.position(channel.position() + len)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132554394 From alanb at openjdk.org Thu Feb 15 13:52:04 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Feb 2024 13:52:04 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:54:12 GMT, Eirik Bj?rsn?s wrote: > Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:) That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132625710 From eirbjo at openjdk.org Thu Feb 15 13:52:05 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:05 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 16:58:38 GMT, Alan Bateman wrote: >> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:), but that doesn't give me an OutputStream I can pass to ZipOutputStream? >> >> I could use Channels.newOutputStream, but that would not create holes in the sparse files? >> >> My current thinking is that we need the SparseOutputStream to detect that ZIpOutputStream is writing empty bytes and replace that with `channel.position(channel.position() + len)` > >> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:) > > That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file. I opted to create a small-sized Zip64 file instead (see below). This file does not need to be sparse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132852771 From eirbjo at openjdk.org Thu Feb 15 13:52:05 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Thu, 15 Feb 2024 13:52:05 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 20:34:56 GMT, Eirik Bj?rsn?s wrote: >>> Not sure I understand. I could use FileChannel.open with SPARSE (which btw is ignored by the implementation:) >> >> That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file. > > I opted to create a small-sized Zip64 file instead (see below). This file does not need to be sparse. > That is true on platforms where files can be sparse by default. On Windows you'll see this translates to create the file as sparse, it needs to be opt-in when creating the file. Thanks for this info, Alan! While this PR no longer makes use of sparse files, I have applied your comments about FileChannel.open for NTFS in another PR (which does make use of sparse files): https://github.com/openjdk/jdk/pull/12948 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12979#discussion_r1132891686 From dfuchs at openjdk.org Thu Feb 15 15:02:55 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 15 Feb 2024 15:02:55 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import Cleaner and Cleanable are very clear that the cleaning action will be invoked at most once. https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/Cleaner.html As long as the Deallocator cannot be accessed from anywhere else (and that seems the case), it doesn't really need to be idempotent. Making it idempotent is a kind of defense in depth fix - that strictly speaking is not needed. If Cleaner/Cleanable could allow the cleaning action to be invoked twice that would be a major bug - as according to the specification, this should not happen, and therefore most of cleaning actions wouldn't guard against it. If the Deallocator was accessible from anywhere else than the cleaning action then making it idempotent would indeed be necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1946270324 From msheppar at openjdk.org Thu Feb 15 17:01:00 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 15 Feb 2024 17:01:00 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import forget concurrency, forget idempotency, forget safe publication across threads etc. Ask the question what is the Deallocator state representing ... it is encapsulating a native memory address that should be freed by an os::free, and when that has been successfully executed, its state should show that referenced address should no longer be freed, becuse that potential side effects. That's a simple and precise propsition. Why are you trying to justify the use of a record to represent Deallocator state as immutable, when that state is not immutable ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1946584406 From alanb at openjdk.org Thu Feb 15 19:19:56 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Feb 2024 19:19:56 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 16:58:20 GMT, Mark Sheppard wrote: > forget concurrency, forget idempotency, forget safe publication across threads etc. Ask the question what is the Deallocator state representing ... it is encapsulating a native memory address that should be freed by an os::free, and when that has been successfully executed, its state should show that referenced address should no longer be freed, becuse that potential side effects. That's a simple and precise propsition. FileChannelImpl.Closer, NativeBuffer.Deallocator, and the task returned by DatagramChannelImpl.releaserFor are other examples of cleaning actions in this area. They aren't mutable objects. Instead, they are just functions that run at most once to release the resource. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1947033970 From rgiulietti at openjdk.org Fri Feb 16 14:18:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 16 Feb 2024 14:18:55 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v6] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 13:07:20 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/io/DataInputStream.java > > Co-authored-by: Raffaello Giulietti Looks fine. test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java line 2: > 1: /* > 2: * Copyright (c) 2020, 2024, Red Hat Inc. All rights reserved. Suggestion: * Copyright (c) 2020, Red Hat Inc. All rights reserved. * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. AFAIU, we don't update 3rd party copyright notices. test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java line 2: > 1: /* > 2: * Copyright (c) 2020, 2024, Red Hat Inc. All rights reserved. Probably the result of a copy&paste... Suggestion: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. ------------- PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885257935 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1492524358 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1492525025 From pminborg at openjdk.org Fri Feb 16 14:50:57 2024 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 16 Feb 2024 14:50:57 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: <1TfvjJnVXMSfvDkalGT2uWqQ1Fw7lirGFxVs_H5W4Fo=.5575dfc2-a224-4009-9684-a6a0bedb2d1a@github.com> On Thu, 15 Feb 2024 16:58:20 GMT, Mark Sheppard wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use existing UNSAFE static variable >> - Remove unused import > > forget concurrency, forget idempotency, forget safe publication across threads etc. > Ask the question what is the Deallocator state representing ... it is encapsulating a native memory address that should be freed by an os::free, and when that has been successfully executed, its state should show that referenced address should no longer be freed, becuse that potential side effects. > That's a simple and precise propsition. > > Why are you trying to justify the use of a record to represent Deallocator state as immutable, when that state is not immutable I think we have concluded that the Cleaner can only run items at most once and that there is no other way the closers can run. So, with this in mind, can you resolve the issue as "Not an issue" @msheppar ? The old "if (address == 0)" must be old code from before the Cleaner era. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1948519999 From redestad at openjdk.org Fri Feb 16 15:31:07 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 16 Feb 2024 15:31:07 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: References: Message-ID: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java Co-authored-by: Raffaello Giulietti - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java Co-authored-by: Raffaello Giulietti ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/48902ad2..586635e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=05-06 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Fri Feb 16 15:31:08 2024 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 16 Feb 2024 15:31:08 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v6] In-Reply-To: References: Message-ID: On Thu, 15 Feb 2024 13:07:20 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/io/DataInputStream.java > > Co-authored-by: Raffaello Giulietti Thanks! I know Roger is out this week, and this can wait until he's had a chance to take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17734#issuecomment-1948619951 From rgiulietti at openjdk.org Fri Feb 16 15:37:55 2024 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 16 Feb 2024 15:37:55 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java > > Co-authored-by: Raffaello Giulietti > - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java > > Co-authored-by: Raffaello Giulietti Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885434083 From bpb at openjdk.org Fri Feb 16 17:19:59 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 16 Feb 2024 17:19:59 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java > > Co-authored-by: Raffaello Giulietti > - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java > > Co-authored-by: Raffaello Giulietti Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1885630906 From duke at openjdk.org Sun Feb 18 03:28:54 2024 From: duke at openjdk.org (yaqsun) Date: Sun, 18 Feb 2024 03:28:54 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). Please review my pr. Thank you very much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1950894522 From alanb at openjdk.org Sun Feb 18 08:20:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 Feb 2024 08:20:53 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: <2KDjekdxYuzce1DIQ5D7PKWq94vNC0BUEdbarVtJ-pQ=.5e4a1df3-46ae-4048-a731-03cc323dcb8e@github.com> On Sun, 18 Feb 2024 03:26:40 GMT, yaqsun wrote: > Please review my pr. I don't think the exchange so far has clearly established the issue. It is likely related to the permissions on /tmp on this system but maybe there is a umask setting in the picture too. In any case, I think it's better if this test uses the work directory rather than /tmp. You'll need to change the static initializer where it first tests if underlying file store support POSIX file permissions. Also in the op method it would be nicer if you used something like `Path dir = Path.of(".");` so you have a Path to the directory for the 4 places that use it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1951001166 From jpai at openjdk.org Sun Feb 18 12:24:56 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 18 Feb 2024 12:24:56 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4GB disk space during builds removes a dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. I ran this test-only change against our CI plus specifically against Oracle Linux 9, where this test was previously failing. All tests passed. So this looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1951280533 From eirbjo at openjdk.org Sun Feb 18 13:39:56 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 18 Feb 2024 13:39:56 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: On Sun, 18 Feb 2024 12:22:02 GMT, Jaikiran Pai wrote: > I ran this test-only change against our CI plus specifically against Oracle Linux 9, where this test was previously failing. All tests passed. So this looks good to me. Thanks @jaikiran. This PR was approved by Lance March last year. There have been some minor updates after that. It would be good to see an approval of this PR in its current state before I integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12979#issuecomment-1951328570 From lancea at openjdk.org Sun Feb 18 15:00:54 2024 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 18 Feb 2024 15:00:54 GMT Subject: RFR: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: <_-KSF_i6edjjleBp4lRHdMU8ffiKZWdadS8aVvHJGrQ=.ecc6e524-7a0d-41c3-958a-b02e818efa9e@github.com> On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4 GB disk space during builds and removes a brittle dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/12979#pullrequestreview-1887257569 From eirbjo at openjdk.org Sun Feb 18 15:28:58 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 18 Feb 2024 15:28:58 GMT Subject: Integrated: 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line In-Reply-To: References: Message-ID: <3q4OuZ6NXCNHHK3e9FpzeQwBMjUrCBG-u-BQ2p4N3WQ=.54f98be6-52ab-4901-a515-42570da4161a@github.com> On Fri, 10 Mar 2023 15:10:29 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which brings the currenly problem-listed test TestLocOffsetFromZip64EF back to life. > > Instead of calling out to the `zip` command line, we produce a small-sized Zip64 file in the test itself. This file has the features required to reproduce the ZipFileSystem issue, namely that the 'INFO-ZIP extended timestamp' field must come before the 'Zip64 extended information' field. (This would casue ZipFileSystem to read the LOC at position 0xFFFFFFFF). > > This speed up the test (from 50s to 3s on my Macbook Pro), saves 4 GB disk space during builds and removes a brittle dependency on the `zip` command in OS/distros. > > Seee [JDK-8301183](https://bugs.openjdk.org/browse/JDK-8301183) for details on the problem-listing. This pull request has now been integrated. Changeset: 7004c272 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/7004c2724d9b150112c66febb7f24b781ff379dd Stats: 209 lines in 2 files changed: 90 ins; 44 del; 75 mod 8303972: (zipfs) Make test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java independent of the zip command line 8301183: (zipfs) jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java failing with ZipException:R0 on OL9 Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/12979 From duke at openjdk.org Mon Feb 19 01:53:21 2024 From: duke at openjdk.org (yaqsun) Date: Mon, 19 Feb 2024 01:53:21 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v2] In-Reply-To: References: Message-ID: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). yaqsun has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8322881 - 8322881: Method createTempFile() causes file copy permission issue when running through jtreg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17235/files - new: https://git.openjdk.org/jdk/pull/17235/files/02c90ed4..4ee537c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=00-01 Stats: 97582 lines in 3281 files changed: 50032 ins; 25612 del; 21938 mod Patch: https://git.openjdk.org/jdk/pull/17235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17235/head:pull/17235 PR: https://git.openjdk.org/jdk/pull/17235 From duke at openjdk.org Mon Feb 19 09:50:18 2024 From: duke at openjdk.org (yaqsun) Date: Mon, 19 Feb 2024 09:50:18 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v3] In-Reply-To: References: Message-ID: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). yaqsun has updated the pull request incrementally with one additional commit since the last revision: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17235/files - new: https://git.openjdk.org/jdk/pull/17235/files/4ee537c5..034324c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17235/head:pull/17235 PR: https://git.openjdk.org/jdk/pull/17235 From msheppar at openjdk.org Mon Feb 19 11:32:56 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 19 Feb 2024 11:32:56 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import which by inference means that change https://bugs.openjdk.org/browse/JDK-8316337 was not required, also. No need for threads safety or safe publication if there is no concurrency involved I can close it but I don't agree with the conclusion. The Deallocator should convey whether the native memory block has been freed or not, and maintained its idempotent characteristic, irrespective of concurrency or at most once semantics. The latter being wholely dependent on correct execution of Cleaner mechanism. At most once semantics should come from the implementation and the current implementation does not exhibit at most once semantics, while the original logic did provide at most once semantics for serial execution. But not for concurrent execution ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1952255025 From alanb at openjdk.org Mon Feb 19 14:44:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Feb 2024 14:44:53 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Mon, 19 Feb 2024 11:30:37 GMT, Mark Sheppard wrote: > which by inference means that change https://bugs.openjdk.org/browse/JDK-8316337 was not required, also. No need for threads safety or safe publication if there is no concurrency involved There is concurrency. The DBB is allocated in one thread, the memory backing that DBB is freed by the Cleaner thread. > I can close it but I don't agree with the conclusion. The Deallocator should convey whether the native memory block has been freed or not, and maintained its idempotent characteristic, irrespective of concurrency or at most once semantics. The latter being wholely dependent on correct execution of Cleaner mechanism. At most once semantics should come from the implementation and the current implementation does not exhibit at most once semantics, while the original logic did provide at most once semantics for serial execution. But not for concurrent execution Let's close it. "At most once" is clearly specified and avoids having every cleaning action (Deallocator is just one of many in the JDK) to have to defend against being called more than once. By "original logic" then I assume you mean the unsafe check for address == 0 and "Paranoia" comment. This pre-dates the migration to the new Cleaner and should probably have been removed a long time to avoid any confusion that it could be called more than once. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1952591786 From pminborg at openjdk.org Mon Feb 19 15:01:59 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 19 Feb 2024 15:01:59 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import The https://bugs.openjdk.org/browse/JDK-8316337 was made to ensure visibility and safe publication between, on the one hand, the thread that allocated the resource and, on the other hand, the distinct cleaner thread. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1952627557 From pminborg at openjdk.org Mon Feb 19 15:02:00 2024 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 19 Feb 2024 15:02:00 GMT Subject: Withdrawn: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 08:41:05 GMT, Per Minborg wrote: > This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. > > There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. > > Passes tier1, 2, and 3 tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17647 From msheppar at openjdk.org Mon Feb 19 17:42:59 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 19 Feb 2024 17:42:59 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import ok, well that's a bit of a subtle one. So you are saying that passing a reference to a Cleaner of the newly constructed Dealloactor doesn't guarantee that Cleaner has a consistent state of the Deallocator, as shown in the code below. That's a bit dubious, as that would imply that every Factory class, or factory method, or object Builder would suffer the same publication effect, when they hand out constructed objects ? try { cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); } catch (Throwable t) { // Prevent leak if the Deallocator or Cleaner fail for any reason UNSAFE.freeMemory(base); Bits.unreserveMemory(size, cap); throw t; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1952938652 From syan at openjdk.org Wed Feb 21 12:19:55 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Feb 2024 12:19:55 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Sun, 28 Jan 2024 15:59:26 GMT, SendaoYan wrote: > 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user This PR only change the testcase, the testcase change has been verified. Please review this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1956526731 From alanb at openjdk.org Wed Feb 21 12:38:57 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Feb 2024 12:38:57 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 12:17:07 GMT, SendaoYan wrote: > This PR only change the testcase, the testcase change has been verified. Please review this PR. @bplb Did you ever run into this? I don't run the tests with root access and haven't seen this. The current changes in pull/17235 aren't complete but if that change goes in then the test won't be testing /tmp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1956557432 From pminborg at openjdk.org Wed Feb 21 16:54:00 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 Feb 2024 16:54:00 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import I am not sure I understand your question. Previously, before we changed to a record. the `address` field was not `final` and hence, we had no safe publication. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1957279602 From msheppar at openjdk.org Wed Feb 21 19:35:59 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 21 Feb 2024 19:35:59 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v4] In-Reply-To: References: Message-ID: On Thu, 8 Feb 2024 10:58:05 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Use existing UNSAFE static variable > - Remove unused import I'm refering to the safe publication of Deallocator via the Cleaner.create code ... the Deallocator reference is stored in a final field in the Cleaner, and the Cleaner is published via a synchronzied method, which I think would represent safe publication of the Deallocator (prior to it being turned into a record) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1957761386 From bpb at openjdk.org Wed Feb 21 21:09:55 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 21 Feb 2024 21:09:55 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v3] In-Reply-To: References: Message-ID: <75qQeeZA8k_iXKM4uD4oCp2djBlc5PtZoj0ANa1cvMw=.1983d89a-25df-4576-93b6-ce4d3c657d48@github.com> On Mon, 19 Feb 2024 09:50:18 GMT, yaqsun wrote: >> testcase: java/nio/file/Files/CopyMoveVariations.java >> >> Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. >> >> The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. >> >> Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8322881: Method createTempFile() causes file copy permission issue when running through jtreg I have not been able to reproduce the failure. I am of the opinion however that the problem is due to something local to the test system, e.g., permissions on `/tmp`, a `umask` setting, etc. That said, I think it's good to change the test directory from `/tmp` to `.` so the change in 034324c0df286203b3b718898c9538f565fb6232 is fine. I will approve this PR tomorrow unless there are objections. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1957935609 From bpb at openjdk.org Wed Feb 21 21:21:53 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 21 Feb 2024 21:21:53 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 12:36:05 GMT, Alan Bateman wrote: > @bplb Did you ever run into this? I don't run the tests with root access and haven't seen this. The current changes in pull/17235 aren't complete but if that change goes in then the test won't be testing /tmp. @AlanBateman No, I have not seen this behavior, nor that addressed in #17235 for that matter. I think that if issue [JDK-8324811](https://bugs.openjdk.org/browse/JDK-8324811) is not reproducible after #17235, then the present PR and its associated issue can be closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1957969669 From tprinzing at openjdk.org Thu Feb 22 01:04:25 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 22 Feb 2024 01:04:25 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v5] In-Reply-To: References: Message-ID: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - update copyright dates - Merge branch 'master' into JDK-8310994 # Conflicts: # src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java # src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java - comment fixup - add select timeout field to the event - Change event generation: - selectNow is filtered out - select that times out is always sent - select without timeout uses duration test - rename event to SelectorSelect, field to selectionKeyCount. - Merge branch 'master' into JDK-8310994 - remove trailing whitespace - event logic outside of the lock, selector in try block - remove unused import - ... and 6 more: https://git.openjdk.org/jdk/compare/36246c97...2e11e84a ------------- Changes: https://git.openjdk.org/jdk/pull/16710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=04 Stats: 321 lines in 9 files changed: 317 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710 From duke at openjdk.org Thu Feb 22 06:25:08 2024 From: duke at openjdk.org (yaqsun) Date: Thu, 22 Feb 2024 06:25:08 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v4] In-Reply-To: References: Message-ID: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). yaqsun has updated the pull request incrementally with one additional commit since the last revision: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17235/files - new: https://git.openjdk.org/jdk/pull/17235/files/034324c0..d6666983 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/17235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17235/head:pull/17235 PR: https://git.openjdk.org/jdk/pull/17235 From syan at openjdk.org Thu Feb 22 13:05:57 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Feb 2024 13:05:57 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 12:36:05 GMT, Alan Bateman wrote: > > This PR only change the testcase, the testcase change has been verified. Please review this PR. > > @bplb Did you ever run into this? I don't run the tests with root access and haven't seen this. The current changes in pull/17235 aren't complete but if that change goes in then the test won't be testing /tmp. Only the jtreg work directory and the /tmp on the different disk partition can replay this fail. ![image](https://github.com/openjdk/jdk/assets/24123821/24af5281-2830-4a4f-b1c3-1c65b0664440) The first jtreg test, the jtreg work directory is in /dev/vda3, and the tmp is in /dev/loop0, so this test run fail. The second jtreg test, use -w options make jtreg directoey point to same to /tmp, this test run success. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1959414716 From syan at openjdk.org Thu Feb 22 15:14:01 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 Feb 2024 15:14:01 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Wed, 21 Feb 2024 21:18:53 GMT, Brian Burkhalter wrote: > > @bplb Did you ever run into this? I don't run the tests with root access and haven't seen this. The current changes in pull/17235 aren't complete but if that change goes in then the test won't be testing /tmp. > > @AlanBateman No, I have not seen this behavior, nor that addressed in #17235 for that matter. I think that if issue [JDK-8324811](https://bugs.openjdk.org/browse/JDK-8324811) is not reproducible after #17235, then the present PR and its associated issue can be closed. This testcase include 3 `Files.move(source, target, options` operations(line 195, line 212, line 232), only the line 195 miss `try catch AccessDeniedException` surround. And for the line 219, when there is a `AccessDeniedException`, then the source file should miss read permission, so `mode.charAt(1) != 'r'` , rather than `mode.charAt(1) != 'w'`. So, it seems that it's a testcase bug cause this testcase run fail at some situation. Maybe this PR is more reasonable more than https://github.com/openjdk/jdk/pull/17235 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1959655669 From bpb at openjdk.org Thu Feb 22 17:34:54 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Feb 2024 17:34:54 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v4] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 06:25:08 GMT, yaqsun wrote: >> testcase: java/nio/file/Files/CopyMoveVariations.java >> >> Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. >> >> The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. >> >> Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8322881: Method createTempFile() causes file copy permission issue when running through jtreg test/jdk/java/nio/file/Files/CopyMoveVariations.java line 2: > 1: /* > 2: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. The copyright needs to be `2023, 2024`, not just `2024`. test/jdk/java/nio/file/Files/CopyMoveVariations.java line 75: > 73: Path tmp = null; > 74: try { > 75: tmp = Files.createTempFile(Path.of("."), "this", "that"); Could you change `tmp` to be a constant, for example private static final Path CURRENT_DIR; (or `CWD`) and change `current` to be `CURRENT_DIR`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17235#discussion_r1499615498 PR Review Comment: https://git.openjdk.org/jdk/pull/17235#discussion_r1499618552 From bpb at openjdk.org Thu Feb 22 21:50:55 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Feb 2024 21:50:55 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: <25Uyft6SVvxKhZaMOQCBqfvX0urA794NpByvk9OV-Ik=.69173fe6-0954-40b6-a339-e9c657ddc214@github.com> References: <25Uyft6SVvxKhZaMOQCBqfvX0urA794NpByvk9OV-Ik=.69173fe6-0954-40b6-a339-e9c657ddc214@github.com> Message-ID: <5yMLkejpfumTCrJI2GOq8yrAx0erkebYCb_SjGiycUY=.327c85ce-9fad-493b-8ee7-05bd45ebdb1f@github.com> On Sun, 28 Jan 2024 16:10:11 GMT, SendaoYan wrote: > Obviously the testcase author run this testcase with root user or privilege users. How could this conjecture be obvious? I am the author of this test and I **never** run tests under anything but my own login, and certainly not as `root` or any other privileged user. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1960373173 From bpb at openjdk.org Thu Feb 22 22:01:54 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Feb 2024 22:01:54 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 15:11:35 GMT, SendaoYan wrote: > This testcase include 3 `Files.move(source, target, options` operations(line 195, line 212, line 232), only the line 195 miss `try catch AccessDeniedException` surround. This is because `AccessDeniedException` is not expected. For a file move operation there is no permission requirement unless the source is a directory, in which case it must be writable. > And for the line 219, when there is a `AccessDeniedException`, then the source file should miss read permission, so `mode.charAt(1) != 'r'` , rather than `mode.charAt(1) != 'w'`. The modes are defined by 99 String[] modes = new String[] { 100 "---------", "r--r--r--", "-w--w--w-", "rw-rw-rw-" 101 }; so I do not see how `mode.charAt(1)` could ever return `r`. Anyway, as a directory and not a file is being moved, the requirement is that the source directory be wrotable so `w` is correct. > So, it seems that it's a testcase bug cause this testcase run fail at some situation. As previously mentioned, we have not seen this in any reasonable scenario. > Maybe this PR is more reasonable than #17235 Actually I think #17235 is more reasonable and that this PR should be withdrawn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1960386141 From syan at openjdk.org Fri Feb 23 01:40:54 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 Feb 2024 01:40:54 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: <5yMLkejpfumTCrJI2GOq8yrAx0erkebYCb_SjGiycUY=.327c85ce-9fad-493b-8ee7-05bd45ebdb1f@github.com> References: <25Uyft6SVvxKhZaMOQCBqfvX0urA794NpByvk9OV-Ik=.69173fe6-0954-40b6-a339-e9c657ddc214@github.com> <5yMLkejpfumTCrJI2GOq8yrAx0erkebYCb_SjGiycUY=.327c85ce-9fad-493b-8ee7-05bd45ebdb1f@github.com> Message-ID: On Thu, 22 Feb 2024 21:47:51 GMT, Brian Burkhalter wrote: > > Obviously the testcase author run this testcase with root user or privilege users. > > How could this conjecture be obvious? > > I am the author of this test and I **never** run tests under anything but my own login, and certainly not as `root` or any other privileged user. Only the jtreg work directory and the /tmp on the different disk partition can replay this fail. As I decsripte https://github.com/openjdk/jdk/pull/17606#issuecomment-1959414716. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1960618684 From syan at openjdk.org Fri Feb 23 02:00:58 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 Feb 2024 02:00:58 GMT Subject: RFR: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 21:58:51 GMT, Brian Burkhalter wrote: > > This testcase include 3 `Files.move(source, target, options` operations(line 195, line 212, line 232), only the line 195 miss `try catch AccessDeniedException` surround. > > This is because `AccessDeniedException` is not expected. For a file move operation there is no permission requirement unless the source is a directory, in which case it must be writable. > > > And for the line 219, when there is a `AccessDeniedException`, then the source file should miss read permission, so `mode.charAt(1) != 'r'` , rather than `mode.charAt(1) != 'w'`. > > The modes are defined by > > ``` > 99 String[] modes = new String[] { > 100 "---------", "r--r--r--", "-w--w--w-", "rw-rw-rw-" > 101 }; > ``` > > so I do not see how `mode.charAt(1)` could ever return `r`. Anyway, as a directory and not a file is being moved, the requirement is that the source directory be wrotable so `w` is correct. > > > So, it seems that it's a testcase bug cause this testcase run fail at some situation. > > As previously mentioned, we have not seen this in any reasonable scenario. > > > Maybe this PR is more reasonable than #17235 > > Actually I think #17235 is more reasonable and that this PR should be withdrawn. In the Linux operating system environment, the file operation permissions may be different if the source and target are in different partitions and if the source and target are in the same partition. I am not professional in this area, so this PR is closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1960632602 From syan at openjdk.org Fri Feb 23 02:00:59 2024 From: syan at openjdk.org (SendaoYan) Date: Fri, 23 Feb 2024 02:00:59 GMT Subject: Withdrawn: 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user In-Reply-To: References: Message-ID: <-aae6OLkl0p9XfK7eYBvfEP9aa7kfkPQq3Tm1OjuK94=.d5166a84-eb94-4b39-b5b4-4425e41a7837@github.com> On Sun, 28 Jan 2024 15:59:26 GMT, SendaoYan wrote: > 8324811: java/nio/file/Files/CopyMoveVariations.java fails run with non-root user This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17606 From duke at openjdk.org Fri Feb 23 06:14:09 2024 From: duke at openjdk.org (yaqsun) Date: Fri, 23 Feb 2024 06:14:09 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v5] In-Reply-To: References: Message-ID: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). yaqsun has updated the pull request incrementally with one additional commit since the last revision: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17235/files - new: https://git.openjdk.org/jdk/pull/17235/files/d6666983..22fcacd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/17235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17235/head:pull/17235 PR: https://git.openjdk.org/jdk/pull/17235 From duke at openjdk.org Fri Feb 23 06:29:55 2024 From: duke at openjdk.org (yaqsun) Date: Fri, 23 Feb 2024 06:29:55 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v4] In-Reply-To: References: Message-ID: On Thu, 22 Feb 2024 17:32:22 GMT, Brian Burkhalter wrote: > Could you change `tmp` to be a constant, for example > > ``` > private static final Path CURRENT_DIR; > ``` 74 try { 75 currentDir = Files.createTempFile(Path.of("."), "this", "that"); 76 SUPPORTS_POSIX_PERMISSIONS = 77 Files.getFileStore(currentDir).supportsFileAttributeView("posix"); 78 } catch (IOException cause) { 79 throw new UncheckedIOException(cause); 80 } finally { 81 if (currentDir != null) { After change tmp to be a constant currentDir, variable currentDir can not be initialized in the finally block. private static final Path currentDir; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17235#discussion_r1500251887 From bpb at openjdk.org Fri Feb 23 16:47:55 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Feb 2024 16:47:55 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v4] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 06:27:33 GMT, yaqsun wrote: > After change tmp to be a constant currentDir, variable currentDir can not be initialized in the finally block. Okay, that's fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17235#discussion_r1500923852 From bpb at openjdk.org Fri Feb 23 17:23:55 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 23 Feb 2024 17:23:55 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v5] In-Reply-To: References: Message-ID: On Fri, 23 Feb 2024 06:14:09 GMT, yaqsun wrote: >> testcase: java/nio/file/Files/CopyMoveVariations.java >> >> Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. >> >> The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. >> >> Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8322881: Method createTempFile() causes file copy permission issue when running through jtreg Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17235#pullrequestreview-1898598911 From duke at openjdk.org Mon Feb 26 10:10:56 2024 From: duke at openjdk.org (yaqsun) Date: Mon, 26 Feb 2024 10:10:56 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp [v5] In-Reply-To: References: Message-ID: <32O6OL7Qu4QwmFrIEtsiSbEbFNne_LqRYAgdW-h0fUA=.2f2ecae1-4ef4-4b3a-bd71-b0364e331536@github.com> On Fri, 23 Feb 2024 06:14:09 GMT, yaqsun wrote: >> testcase: java/nio/file/Files/CopyMoveVariations.java >> >> Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. >> >> The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. >> >> Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > > yaqsun has updated the pull request incrementally with one additional commit since the last revision: > > 8322881: Method createTempFile() causes file copy permission issue when running through jtreg I ran an experiment on existing machines. Running on the following environment can be replicated. NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" and NAME="CentOS Linux" VERSION="8" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" But running on the following environment can not be replicated. NAME="Ubuntu" VERSION="18.04.6 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.6 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic @AlanBateman @bplb Thank you for reminding me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1963750037 From dfuchs at openjdk.org Mon Feb 26 14:26:57 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:26:57 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:58:40 GMT, Tim Prinzing wrote: >> src/java.base/share/classes/jdk/internal/event/SelectorSelectEvent.java line 41: >> >>> 39: public class SelectorSelectEvent extends Event { >>> 40: >>> 41: public int selectionKeyCount; >> >> I still believe we should record the timeout parameter in the event. > > Good point about the wakeup. I'll add the field. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502695847 From dfuchs at openjdk.org Mon Feb 26 14:26:58 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:26:58 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v3] In-Reply-To: References: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> Message-ID: On Wed, 3 Jan 2024 11:11:40 GMT, Alan Bateman wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> add select timeout field to the event > > src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153: > >> 151: if ((n == 0) || (SelectorSelectEvent.shouldCommit(duration))) { >> 152: timeout = (timeout < 0) ? 0 : timeout; >> 153: SelectorSelectEvent.commit(start, duration, n, timeout); > > The comment is a bit confusing here. n == 0 means that no selected keys were added or consumed before timeout or wakeup. Is n == 0 intended to detect a spinning condition where the selector goes back into select when the event has not been handled? In that case should we still emit an event if a timeout is present and the duration is greater than the timeout? For instance, in the HttpClient, we have a selector thread that will wake up at regular interval - we set up a timeout which is the min between the next expected timer event and 1500ms. So that could potentially fire an event every 1500ms if for instance the connection threshold is less than 1500ms and the connection is idle. Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms? Or should it be ((n == 0 && durationToMillis(duration) < timeoutToMillis(timeout)) || ...)) (duration and timeout probably are not in the same unit of time) - also if shouldCommit return false will the event actually be emitted down the road? Because if not then the ( n== 0 || ...) won't work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502681499 From dfuchs at openjdk.org Mon Feb 26 14:27:03 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Feb 2024 14:27:03 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v2] In-Reply-To: References: Message-ID: On Wed, 13 Dec 2023 18:49:08 GMT, Daniel Fuchs wrote: >> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: >> >> - Change event generation: >> >> - selectNow is filtered out >> - select that times out is always sent >> - select without timeout uses duration test >> - rename event to SelectorSelect, field to selectionKeyCount. >> - Merge branch 'master' into JDK-8310994 >> - remove trailing whitespace >> - event logic outside of the lock, selector in try block >> - remove unused import >> - fix TestConfigure failure >> - add event defaults >> - Merge branch 'master' into JDK-8310994 >> - minor test cleanup >> - ... and 2 more: https://git.openjdk.org/jdk/compare/9896b3fb...2f7dafd8 > > src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44: > >> 42: @Label("SelectionKey Count") >> 43: @Description("Number of channels ready for I/O or added to ready set") >> 44: public int selectionKeyCount; > > same here Thanks for adding the timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1502686107 From rriggs at openjdk.org Mon Feb 26 15:54:44 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Feb 2024 15:54:44 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java > > Co-authored-by: Raffaello Giulietti > - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java > > Co-authored-by: Raffaello Giulietti Looks good. src/java.base/share/classes/java/io/DataInputStream.java line 622: > 620: "malformed input around byte " + count); > 621: chararr[chararr_count++]=(char)(((c & 0x1F) << 6) | > 622: (char2 & 0x3F)); Seems like the extra space isn't necessary for alignment. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17734#pullrequestreview-1901248533 PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1502841700 From redestad at openjdk.org Mon Feb 26 16:09:02 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:02 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v8] In-Reply-To: References: Message-ID: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Stray space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17734/files - new: https://git.openjdk.org/jdk/pull/17734/files/586635e8..9929cd87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17734&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17734.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17734/head:pull/17734 PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Mon Feb 26 16:09:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:03 GMT Subject: Integrated: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF In-Reply-To: References: Message-ID: <5HZKzdpcBZUjnkXsxyvXdTSXfVK-pgewV7EiZ4XW2OY=.7e7f7339-d169-4519-baad-7b74e3ef312d@github.com> On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote: > Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via Data- and ObjectInputStream > > Testing: tier1-3 This pull request has now been integrated. Changeset: 9a9cfbe0 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/9a9cfbe0ba18084bbeae212c9e0da2715a3086e7 Stats: 369 lines in 4 files changed: 345 ins; 7 del; 17 mod 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF Reviewed-by: rgiulietti, bpb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/17734 From redestad at openjdk.org Mon Feb 26 16:09:03 2024 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 26 Feb 2024 16:09:03 GMT Subject: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7] In-Reply-To: References: <5W9u4RJXEclgcBrZt6uWlGDcVYFRGJhkqa79PNJjxo8=.46b06cde-865f-447c-b8d6-bf4d80162686@github.com> Message-ID: On Mon, 26 Feb 2024 15:50:55 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java >> >> Co-authored-by: Raffaello Giulietti >> - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java >> >> Co-authored-by: Raffaello Giulietti > > src/java.base/share/classes/java/io/DataInputStream.java line 622: > >> 620: "malformed input around byte " + count); >> 621: chararr[chararr_count++]=(char)(((c & 0x1F) << 6) | >> 622: (char2 & 0x3F)); > > Seems like the extra space isn't necessary for alignment. Fixed, thanks for reviewing! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17734#discussion_r1502894731 From alanb at openjdk.org Mon Feb 26 17:43:44 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Feb 2024 17:43:44 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v3] In-Reply-To: References: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> Message-ID: On Mon, 26 Feb 2024 14:14:21 GMT, Daniel Fuchs wrote: > Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms? The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1503052233 From duke at openjdk.org Mon Feb 26 20:50:48 2024 From: duke at openjdk.org (yaqsun) Date: Mon, 26 Feb 2024 20:50:48 GMT Subject: Integrated: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). This pull request has now been integrated. Changeset: bf13a4e2 Author: sunyaqi Committer: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/bf13a4e2819fa5bcb3e4f2281121d4e0b5535403 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/17235 From bpb at openjdk.org Wed Feb 28 03:17:03 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 03:17:03 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support Message-ID: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. ------------- Commit messages: - 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support Changes: https://git.openjdk.org/jdk/pull/18038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326897 Stats: 26 lines in 3 files changed: 21 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/18038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18038/head:pull/18038 PR: https://git.openjdk.org/jdk/pull/18038 From gli at openjdk.org Wed Feb 28 06:37:53 2024 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 28 Feb 2024 06:37:53 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 03:12:17 GMT, Brian Burkhalter wrote: > Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. Look goods. A possible problem is the unmatched method names. Generally, the method `Files.createSymbolicLink` may match `TestUtil.supportsSymbolicLinks` instead of `TestUtil.supportsLinks`. And the `Files.createLink` may match `TestUtil.supportsLinks` or `TestUtil.supportsHardLinks`. But they are just test code, so I think the current patch is OK. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18038#pullrequestreview-1905421335 From bpb at openjdk.org Wed Feb 28 08:03:52 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 08:03:52 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 06:35:35 GMT, Guoxiong Li wrote: > But they are just test code, so I think the current patch is OK. I investigated this, and I agree that it would be better to make things more consistent, but I do not think that all the editing is worth it here in the test code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18038#issuecomment-1968425729 From alanb at openjdk.org Wed Feb 28 12:34:44 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Feb 2024 12:34:44 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 08:00:42 GMT, Brian Burkhalter wrote: > > But they are just test code, so I think the current patch is OK. > > I investigated this, and I agree that it would be better to make things more consistent, but I do not think that all the editing is worth it here in the test code. I see 18 tests are using Test.supportsLink so won't be too much to migrate them to supportsSymbolicLink if you want. It can be done in another PR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18038#issuecomment-1968887012 From bpb at openjdk.org Wed Feb 28 15:34:52 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 15:34:52 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 12:32:16 GMT, Alan Bateman wrote: > I see 18 tests are using Test.supportsLink so won't be too much to migrate them to supportsSymbolicLink if you want. It can be done in another PR too. Yes, I decided I was just being lazy. I think in any case doing it in the first pass would have obfuscated things a bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18038#issuecomment-1969238844 From bpb at openjdk.org Wed Feb 28 17:14:19 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 17:14:19 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support [v2] In-Reply-To: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: <8HdGqv77kY8fK-3cyJT0D2iMN0ra-tDGpTOYAvDd6DU=.f5547312-75a5-437b-a7c7-2baed4ce2eed@github.com> > Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8326897: supportsLinks -> supportsSymbolicLinks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18038/files - new: https://git.openjdk.org/jdk/pull/18038/files/dcac6971..255c4850 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18038&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18038&range=00-01 Stats: 87 lines in 18 files changed: 1 ins; 0 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/18038.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18038/head:pull/18038 PR: https://git.openjdk.org/jdk/pull/18038 From bpb at openjdk.org Wed Feb 28 17:14:19 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 17:14:19 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 03:12:17 GMT, Brian Burkhalter wrote: > Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. Test method name changed in 255c485. Compiles and passes on all platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18038#issuecomment-1969458421 From alanb at openjdk.org Wed Feb 28 17:26:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Feb 2024 17:26:53 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support [v2] In-Reply-To: <8HdGqv77kY8fK-3cyJT0D2iMN0ra-tDGpTOYAvDd6DU=.f5547312-75a5-437b-a7c7-2baed4ce2eed@github.com> References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> <8HdGqv77kY8fK-3cyJT0D2iMN0ra-tDGpTOYAvDd6DU=.f5547312-75a5-437b-a7c7-2baed4ce2eed@github.com> Message-ID: On Wed, 28 Feb 2024 17:14:19 GMT, Brian Burkhalter wrote: >> Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8326897: supportsLinks -> supportsSymbolicLinks If tier2 is passing then you should be good to go. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18038#pullrequestreview-1906843217 From bpb at openjdk.org Wed Feb 28 17:26:53 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 17:26:53 GMT Subject: RFR: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support [v2] In-Reply-To: References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> <8HdGqv77kY8fK-3cyJT0D2iMN0ra-tDGpTOYAvDd6DU=.f5547312-75a5-437b-a7c7-2baed4ce2eed@github.com> Message-ID: On Wed, 28 Feb 2024 17:22:07 GMT, Alan Bateman wrote: > If tier2 is passing then you should be good to go. I only ran `java/nio/file` but will run `tier2` as well, at a minimum. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18038#issuecomment-1969482571 From bpb at openjdk.org Wed Feb 28 18:01:05 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 28 Feb 2024 18:01:05 GMT Subject: RFR: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc Message-ID: Insert missing `in` in the specification of `ScatteringByteChannel.read`. ------------- Commit messages: - 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc Changes: https://git.openjdk.org/jdk/pull/18049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326944 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18049/head:pull/18049 PR: https://git.openjdk.org/jdk/pull/18049 From naoto at openjdk.org Wed Feb 28 18:07:44 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 28 Feb 2024 18:07:44 GMT Subject: RFR: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 17:56:35 GMT, Brian Burkhalter wrote: > Insert missing `in` in the specification of `ScatteringByteChannel.read`. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18049#pullrequestreview-1906932356 From iris at openjdk.org Wed Feb 28 18:14:52 2024 From: iris at openjdk.org (Iris Clark) Date: Wed, 28 Feb 2024 18:14:52 GMT Subject: RFR: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 17:56:35 GMT, Brian Burkhalter wrote: > Insert missing `in` in the specification of `ScatteringByteChannel.read`. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18049#pullrequestreview-1906945363 From coffeys at openjdk.org Wed Feb 28 18:48:51 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 28 Feb 2024 18:48:51 GMT Subject: RFR: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 17:56:35 GMT, Brian Burkhalter wrote: > Insert missing `in` in the specification of `ScatteringByteChannel.read`. Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18049#pullrequestreview-1907014086 From bpb at openjdk.org Thu Feb 29 01:25:12 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 Feb 2024 01:25:12 GMT Subject: RFR: 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java should be able to test across file systems Message-ID: 1. Modify the test to allow specifying the location of the temporary directory to be distinct from that of the working directory. 2. Correctly handle the responses to `AccessDeniedException`s which occur when a move across different file systems fails. ------------- Commit messages: - 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java should be able to test across file systems Changes: https://git.openjdk.org/jdk/pull/18052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327002 Stats: 39 lines in 1 file changed: 27 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/18052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18052/head:pull/18052 PR: https://git.openjdk.org/jdk/pull/18052 From bpb at openjdk.org Thu Feb 29 01:25:12 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 Feb 2024 01:25:12 GMT Subject: RFR: 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java should be able to test across file systems In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 01:19:40 GMT, Brian Burkhalter wrote: > 1. Modify the test to allow specifying the location of the temporary directory to be distinct from that of the working directory. > 2. Correctly handle the responses to `AccessDeniedException`s which occur when a move across different file systems fails. 1. Add property `copymove.tmp.dir` which can be set to specify the temporary file directory (`java.io.tmpdir` could simply be used instead but is not for now). 2. Correct handling of `AccessDeniedException`s occurring for `Files.move` when the source is a directory or a file and the move is to a different file system. 3. Rename various local variables. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18052#issuecomment-1970208802 From gli at openjdk.org Thu Feb 29 09:39:53 2024 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 29 Feb 2024 09:39:53 GMT Subject: RFR: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 17:56:35 GMT, Brian Burkhalter wrote: > Insert missing `in` in the specification of `ScatteringByteChannel.read`. LGTM. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/jdk/pull/18049#pullrequestreview-1908394505 From prappo at openjdk.org Thu Feb 29 13:02:12 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Feb 2024 13:02:12 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order Message-ID: Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/18063/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327046 Stats: 17 lines in 2 files changed: 2 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/18063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18063/head:pull/18063 PR: https://git.openjdk.org/jdk/pull/18063 From prappo at openjdk.org Thu Feb 29 13:06:04 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Feb 2024 13:06:04 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v2] In-Reply-To: References: Message-ID: > Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Oops. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18063/files - new: https://git.openjdk.org/jdk/pull/18063/files/6c6a242b..4240524b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/18063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18063/head:pull/18063 PR: https://git.openjdk.org/jdk/pull/18063 From alanb at openjdk.org Thu Feb 29 13:48:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Feb 2024 13:48:54 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v2] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 13:06:04 GMT, Pavel Rappo wrote: >> Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Oops. Your proposed wording is okay but it makes me wonder if we now need to define "pre-order" as it is new term here. An alternative is something like this: "The file tree traversal is depth-first with a directory visited before the entries in the directory." which will align it closely to the existing wording in walkFileTree and FileVisitor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18063#issuecomment-1971181170 From prappo at openjdk.org Thu Feb 29 15:03:18 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Feb 2024 15:03:18 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v3] In-Reply-To: References: Message-ID: > Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Respond to feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/18063/files - new: https://git.openjdk.org/jdk/pull/18063/files/4240524b..5ffccf38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18063&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/18063.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18063/head:pull/18063 PR: https://git.openjdk.org/jdk/pull/18063 From prappo at openjdk.org Thu Feb 29 15:03:18 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 29 Feb 2024 15:03:18 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v2] In-Reply-To: References: Message-ID: On Thu, 29 Feb 2024 13:06:04 GMT, Pavel Rappo wrote: >> Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Oops. You are right. Although in-order, pre-order and post-order are all well-known terms, there are no occurrences of them in the java.base API documentation. Fixed closely to what you proposed; please examine 5ffccf3. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18063#issuecomment-1971325845 From alanb at openjdk.org Thu Feb 29 15:22:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Feb 2024 15:22:53 GMT Subject: RFR: 8327046: (fs) Files.walk should be clear that depth-first traversal is pre-order [v3] In-Reply-To: References: Message-ID: <3xyzVaFvBZpBr5NCDgcNfZ_Rfneow9vwt0uqCHlau7Y=.be805d8e-27f4-49ce-baa6-5e2282488aaa@github.com> On Thu, 29 Feb 2024 15:03:18 GMT, Pavel Rappo wrote: >> Please review this clarification to the specification of the two overloads of `java.nio.file.Files.walk`. No tests are added, as I believe the existing `StreamTest.testWalk*` methods already test the order sufficiently. I also took this opportunity to fix a few minor typos. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Respond to feedback Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/18063#pullrequestreview-1909173995 From bpb at openjdk.org Thu Feb 29 16:49:57 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 Feb 2024 16:49:57 GMT Subject: Integrated: 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support In-Reply-To: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> References: <3MFbfrYfRFGHJYKgY4bZFDzxfSPZQcKx9WzJCqTLcjM=.a5dfd90c-a4fd-462d-9e70-63488a1afcd5@github.com> Message-ID: On Wed, 28 Feb 2024 03:12:17 GMT, Brian Burkhalter wrote: > Add to `test/jdk/java/nio/file/TestUtil.java` the method `TestUtil.supportsHardLinks` and use it to conditionally test `Files.createLink` where appropriate in the `java/nio/file` tests. This pull request has now been integrated. Changeset: bbfda659 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/bbfda6599a878746cd0bab72952deae95e9f5dea Stats: 113 lines in 18 files changed: 22 ins; 1 del; 90 mod 8326897: (fs) The utility TestUtil.supportsLinks is wrongly used to check for hard link support Reviewed-by: gli, alanb ------------- PR: https://git.openjdk.org/jdk/pull/18038 From bpb at openjdk.org Thu Feb 29 16:49:57 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 Feb 2024 16:49:57 GMT Subject: Integrated: 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc In-Reply-To: References: Message-ID: On Wed, 28 Feb 2024 17:56:35 GMT, Brian Burkhalter wrote: > Insert missing `in` in the specification of `ScatteringByteChannel.read`. This pull request has now been integrated. Changeset: db0e2b8f Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/db0e2b8faf41b1dcf3cb8e637e213f50ced92584 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8326944: (ch) Minor typo in the ScatteringByteChannel.read(ByteBuffer[] dsts,int offset,int length) javadoc Reviewed-by: naoto, iris, coffeys, gli ------------- PR: https://git.openjdk.org/jdk/pull/18049 From bpb at openjdk.org Thu Feb 29 23:53:14 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 Feb 2024 23:53:14 GMT Subject: RFR: 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails Message-ID: Add to the error message of the `IOException` thrown when the `mkfifo` command fails: 1. the absolute path of the FIFO which was to have been created; 2. the text read from the standard error stream of the process in which `mkfifo` was executed. ------------- Commit messages: - 8327095: (ch) java/nio/channels/AsyncCloseAndInterrupt.java: improve error message when mkfifo fails Changes: https://git.openjdk.org/jdk/pull/18072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327095 Stats: 10 lines in 1 file changed: 6 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/18072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18072/head:pull/18072 PR: https://git.openjdk.org/jdk/pull/18072