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 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: <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 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: <_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 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 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: