From alanb at openjdk.org Tue Jan 2 15:23:13 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Jan 2024 15:23:13 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock Message-ID: In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/17219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322829 Stats: 141 lines in 6 files changed: 87 ins; 25 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/17219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17219/head:pull/17219 PR: https://git.openjdk.org/jdk/pull/17219 From bpb at openjdk.org Tue Jan 2 17:05:52 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Jan 2024 17:05:52 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v2] In-Reply-To: References: Message-ID: <212nZwD65jV6gzmlkk9ULT5QGCMs808QB6TtIMGzdbs=.4409bc98-7353-4771-8e3e-0243459b3b66@github.com> On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > 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 three additional commits since the last revision: > > - 8298318: Correct type in path.getExtension spec > - Merge > - 8298318: (fs) APIs for handling filename extensions continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1874295535 From duke at openjdk.org Wed Jan 3 03:37:59 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 3 Jan 2024 03:37:59 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg Message-ID: testcase: java/nio/file/Files/CopyMoveVariations.java Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. Create files and directories for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). ------------- Commit messages: - 8322881: Method createTempFile() causes file copy permission issue when running through jtreg Changes: https://git.openjdk.org/jdk/pull/17234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322881 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17234/head:pull/17234 PR: https://git.openjdk.org/jdk/pull/17234 From duke at openjdk.org Wed Jan 3 03:42:06 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 3 Jan 2024 03:42:06 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg [v2] In-Reply-To: References: Message-ID: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. > > Create files and directories for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). yaqsun has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17234/files - new: https://git.openjdk.org/jdk/pull/17234/files/4ea10f6f..fcf8368e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17234&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17234&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17234.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17234/head:pull/17234 PR: https://git.openjdk.org/jdk/pull/17234 From duke at openjdk.org Wed Jan 3 03:42:06 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 3 Jan 2024 03:42:06 GMT Subject: Withdrawn: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:32:04 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. > > Create files and directories for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/17234 From duke at openjdk.org Wed Jan 3 03:46:55 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 3 Jan 2024 03:46:55 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg Message-ID: testcase: java/nio/file/Files/CopyMoveVariations.java Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. Create files and directories for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). ------------- Commit messages: - 8322881: Method createTempFile() causes file copy permission issue when running through jtreg Changes: https://git.openjdk.org/jdk/pull/17235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322881 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17235.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17235/head:pull/17235 PR: https://git.openjdk.org/jdk/pull/17235 From bpb at openjdk.org Wed Jan 3 04:05:46 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Jan 2024 04:05:46 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg In-Reply-To: References: Message-ID: <2sY_vU8z5MRb98DvFvWOXWDYFTjFn0jaB7TwqnLOWmE=.f9433c43-14c8-486e-8196-1a36e426443a@github.com> On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. The method call `Files.createTempFile("file", "dat")` creates a file named "fileXdat" in the default temporary file directory "/tmp" where `X` denotes a large integer. It does not create a directory per se. Could this problem instead be due to permissions on the default temporary file directory "/tmp" on the test system involved? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1874823364 From duke at openjdk.org Wed Jan 3 04:37:36 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 3 Jan 2024 04:37:36 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > > Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. > > Could this problem instead be due to permissions on the default temporary file directory "/tmp" on the test system involved? Yes, the default temporary file directory "/tmp" causes permission issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1874839360 From alanb at openjdk.org Wed Jan 3 06:45:47 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Jan 2024 06:45:47 GMT Subject: RFR: 8322881: Method createTempFile() causes file copy permission issue when running through jtreg In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). I changed the title of the issue in JBS to make it clear that this is an issue with the test and file permissions and not a bug in createTempFile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1874914210 From alanb at openjdk.org Wed Jan 3 11:14:49 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Jan 2024 11:14:49 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v3] In-Reply-To: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> References: <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com> Message-ID: On Wed, 13 Dec 2023 22:20:55 GMT, Tim Prinzing wrote: >> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. >> >> Emit the event from SelectorImpl::lockAndDoSelect >> >> Test at jdk.jfr.event.io.TestSelectionEvents > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > add select timeout field to the event src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 143: > 141: throws IOException > 142: { > 143: // filter selectNow ops from consideration (timeout == 0) I think simplify this comment to say no JFR event for selectNow. src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 153: > 151: if ((n == 0) || (SelectorSelectEvent.shouldCommit(duration))) { > 152: timeout = (timeout < 0) ? 0 : timeout; > 153: SelectorSelectEvent.commit(start, duration, n, timeout); The comment is a bit confusing here. n == 0 means that no selected keys were added or consumed before timeout or wakeup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1440332584 PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1440332569 From bpb at openjdk.org Wed Jan 3 19:55:20 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Jan 2024 19:55:20 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDenieException due to permissions of files in /tmp In-Reply-To: References: Message-ID: <8MSfsaN2grje4B8l6oD6q0-_gOlb57JVO9BZPiRTkA8=.8b1e9c9f-0844-4188-9b9c-38d462f9469c@github.com> On Wed, 3 Jan 2024 04:35:09 GMT, yaqsun wrote: > Yes, the default temporary file directory "/tmp" causes permission issues. Is this issue then perhaps a problem with the system which should not require a change to the test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1875888422 From bpb at openjdk.org Wed Jan 3 19:59:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Jan 2024 19:59:25 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDenieException due to permissions of files in /tmp In-Reply-To: References: Message-ID: <-LC7BGrWs0X42bjU3oscBVfV0WslSQ8F671ghvC_9bU=.fd6f3097-8f71-4029-9155-33a6ae7aafe1@github.com> On Wed, 3 Jan 2024 04:35:09 GMT, yaqsun wrote: >> testcase: java/nio/file/Files/CopyMoveVariations.java >> >> Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. >> >> Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). > >> > Method createTempFile() creates "/tmp/file*" directory that it causes file copy permission issue when running through jtreg. >> >> Could this problem instead be due to permissions on the default temporary file directory "/tmp" on the test system involved? > > Yes, the default temporary file directory "/tmp" causes permission issues. @yaqsun Sorry, but I corrected a typo in the issue title so you will again need to change the title of this request to match. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1875893155 From duke at openjdk.org Thu Jan 4 02:04:21 2024 From: duke at openjdk.org (yaqsun) Date: Thu, 4 Jan 2024 02:04:21 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: <8MSfsaN2grje4B8l6oD6q0-_gOlb57JVO9BZPiRTkA8=.8b1e9c9f-0844-4188-9b9c-38d462f9469c@github.com> References: <8MSfsaN2grje4B8l6oD6q0-_gOlb57JVO9BZPiRTkA8=.8b1e9c9f-0844-4188-9b9c-38d462f9469c@github.com> Message-ID: On Wed, 3 Jan 2024 19:52:44 GMT, Brian Burkhalter wrote: > > Yes, the default temporary file directory "/tmp" causes permission issues. > > Is this issue then perhaps a problem with the system which should not require a change to the test? The issue is unrelated to system, as the issue is repeated when running with Jtreg command. jtreg/bin/jtreg -dir:test/jdk -testjdk:./** java/nio/file/Files/CopyMoveVariations.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1876207601 From duke at openjdk.org Thu Jan 4 02:04:22 2024 From: duke at openjdk.org (yaqsun) Date: Thu, 4 Jan 2024 02:04:22 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: <8MSfsaN2grje4B8l6oD6q0-_gOlb57JVO9BZPiRTkA8=.8b1e9c9f-0844-4188-9b9c-38d462f9469c@github.com> Message-ID: On Thu, 4 Jan 2024 02:01:06 GMT, yaqsun wrote: >>> Yes, the default temporary file directory "/tmp" causes permission issues. >> >> Is this issue then perhaps a problem with the system which should not require a change to the test? > >> > Yes, the default temporary file directory "/tmp" causes permission issues. >> >> Is this issue then perhaps a problem with the system which should not require a change to the test? > > The issue is unrelated to system, as the issue is repeated when running with Jtreg command. > > jtreg/bin/jtreg -dir:test/jdk -testjdk:./** java/nio/file/Files/CopyMoveVariations.java > @yaqsun Sorry, but I corrected a typo in the issue title so you will again need to change the title of this request to match. The title have been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1876208085 From alanb at openjdk.org Thu Jan 4 12:33:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Jan 2024 12:33:32 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown Message-ID: InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. ------------- Commit messages: - Add asserts to test that channel is closed - Speed up test - Initial commit Changes: https://git.openjdk.org/jdk/pull/17251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319757 Stats: 160 lines in 1 file changed: 54 ins; 29 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/17251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17251/head:pull/17251 PR: https://git.openjdk.org/jdk/pull/17251 From alanb at openjdk.org Thu Jan 4 12:54:34 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Jan 2024 12:54:34 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown [v2] In-Reply-To: References: Message-ID: > InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. > > The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Fix comment in testInterruptDuringUninterruptibleReceive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17251/files - new: https://git.openjdk.org/jdk/pull/17251/files/ac9e6ab4..6f6fc4c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17251&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17251&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17251/head:pull/17251 PR: https://git.openjdk.org/jdk/pull/17251 From bpb at openjdk.org Thu Jan 4 21:19:29 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 4 Jan 2024 21:19:29 GMT Subject: RFR: 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer Message-ID: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> Attempt to clarify when the values returned for a `FileStore`s usable and unallocated space are initialized and likely to be valid. ------------- Commit messages: - 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer Changes: https://git.openjdk.org/jdk/pull/17271/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17271&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7057369 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17271/head:pull/17271 PR: https://git.openjdk.org/jdk/pull/17271 From alanb at openjdk.org Fri Jan 5 14:11:24 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 14:11:24 GMT Subject: RFR: 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer In-Reply-To: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> References: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> Message-ID: <9mcZzslgDsu6la84FT-FrbdjHprh0ORZdzG_6JT7C9k=.961bfffa-25e9-4ff4-b48c-ddc1348f9451@github.com> On Thu, 4 Jan 2024 21:15:18 GMT, Brian Burkhalter wrote: > Attempt to clarify when the values returned for a `FileStore`s usable and unallocated space are initialized and likely to be valid. src/java.base/share/classes/java/nio/file/FileStore.java line 102: > 100: * virtual machine as of invoking this method. If the number of bytes > 101: * available is greater than {@link Long#MAX_VALUE}, then > 102: * {@code Long.MAX_VALUE} will be returned. I think the original paragraph is okay. The change to the second paragraph looks good. src/java.base/share/classes/java/nio/file/FileStore.java line 111: > 109: * of this Java virtual machine. > 110: * > 111: * @return the number of bytes available at the time of invocation It might be simpler to just say "the current number of usable bytes". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17271#discussion_r1442930275 PR Review Comment: https://git.openjdk.org/jdk/pull/17271#discussion_r1442929597 From jpai at openjdk.org Fri Jan 5 16:09:22 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 16:09:22 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown [v2] In-Reply-To: References: Message-ID: <3ZjYlbhNYE9FX5bhyl2wLF_wbmPMDUbbzyq6ZKQJL-w=.7730ab17-3450-4faa-a43e-51e7a7285574@github.com> On Thu, 4 Jan 2024 12:54:34 GMT, Alan Bateman wrote: >> InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. >> >> The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment in testInterruptDuringUninterruptibleReceive The test changes look OK to me. Given that these are unconnected DatagramChannels, do you think this test is susceptible to receiving unexpected packets (in CI environments) and can run into intermittent failures (receive completing successfully before being interrupted)? Would making them connected (to a test specific address that never sends anything) improve the situation or would that then take a different code path than what this test intends to test? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17251#pullrequestreview-1806240526 From jpai at openjdk.org Fri Jan 5 16:22:25 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 16:22:25 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: <8MSfsaN2grje4B8l6oD6q0-_gOlb57JVO9BZPiRTkA8=.8b1e9c9f-0844-4188-9b9c-38d462f9469c@github.com> Message-ID: On Thu, 4 Jan 2024 02:01:55 GMT, yaqsun wrote: >>> > Yes, the default temporary file directory "/tmp" causes permission issues. >>> >>> Is this issue then perhaps a problem with the system which should not require a change to the test? >> >> The issue is unrelated to system, as the issue is repeated when running with Jtreg command. >> >> jtreg/bin/jtreg -dir:test/jdk -testjdk:./** java/nio/file/Files/CopyMoveVariations.java > >> @yaqsun Sorry, but I corrected a typo in the issue title so you will again need to change the title of this request to match. > > The title have been updated. Hello @yaqsun, I just did a search for "Files.createTempFile" under `/test/jdk` directory: grep "Files.createTempFile" ./test/jdk -R There are numerous tests within the JDK which do that call without passing the call a directory under which to create these temporary files, just like this `CopyMoveVariations`. Are those tests passing for you on this system and only this specific one fails? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1878928602 From bpb at openjdk.org Fri Jan 5 16:33:35 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Jan 2024 16:33:35 GMT Subject: RFR: 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer [v2] In-Reply-To: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> References: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> Message-ID: > Attempt to clarify when the values returned for a `FileStore`s usable and unallocated space are initialized and likely to be valid. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17271/files - new: https://git.openjdk.org/jdk/pull/17271/files/7d10b049..0df648db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17271&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17271&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17271.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17271/head:pull/17271 PR: https://git.openjdk.org/jdk/pull/17271 From bpb at openjdk.org Fri Jan 5 16:39:24 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 5 Jan 2024 16:39:24 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 12:54:34 GMT, Alan Bateman wrote: >> InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. >> >> The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment in testInterruptDuringUninterruptibleReceive Looks good insofar as I know this area. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17251#pullrequestreview-1806364790 From jpai at openjdk.org Fri Jan 5 16:41:21 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 16:41:21 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). Reading through the stacktrace in the linked JBS issue, it appears that it's not the "Files.createTempFile" which is failing but the `Files.move` appears to be failing, unable to move a temporary file (which has `000` posix permission) that was created by the test in the default filesystem's temporary directory, to a non-existent target file on the same filesystem. The copy operation in the `UnixFileSystem` is where this is failing to open the source file. You might have to debug that code a bit to see how that default temporary directory is setup and different from other systems where this is passing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1878955313 From jpai at openjdk.org Fri Jan 5 16:54:22 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 16:54:22 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. src/java.base/share/classes/sun/nio/ch/Interruptible.java line 38: > 36: * is invoked while holding the Thread's interrupt lock. It will typically record > 37: * that the I/O operation has been interrupted so that it can be coordinated with > 38: * {@code postInterrupt} when it called after releasing the Thread's interrupt Should have been "when it is called" instead of "when it called" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443114966 From alanb at openjdk.org Fri Jan 5 17:04:25 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 17:04:25 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: <-sYfziy_WhMvavWAPKwT5OYwP5_a_KkAdjlfiaw0Gao=.4f9e5b5a-1bea-4989-af0e-31a87c4f9633@github.com> On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). I suspect the yaqsun runs into with this test because this test is testing file permissions. Most of the other tests that end up using the system tmp directory won't be as sensitive to the file permissions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1878987504 From alanb at openjdk.org Fri Jan 5 17:04:25 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 17:04:25 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: <7sPiUtGp8YhbaL61DhcpZH-bf7E82J4FG7iR-ZbDQDQ=.9db73a3b-949e-43b6-8323-3ba5412125c5@github.com> On Fri, 5 Jan 2024 16:51:40 GMT, Jaikiran Pai wrote: >> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. > > src/java.base/share/classes/sun/nio/ch/Interruptible.java line 38: > >> 36: * is invoked while holding the Thread's interrupt lock. It will typically record >> 37: * that the I/O operation has been interrupted so that it can be coordinated with >> 38: * {@code postInterrupt} when it called after releasing the Thread's interrupt > > Should have been "when it is called" instead of "when it called" Thanks, this is typo there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443123893 From jpai at openjdk.org Fri Jan 5 17:04:28 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:04:28 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. src/java.base/share/classes/sun/nio/ch/Interruptible.java line 49: > 47: * Selector. This method is required to be idempotent. > 48: */ > 49: void postInterrupt(); Should there be any thread safety note/expectations on this method now that it can be potentially called concurrently by multiple threads since it's called outside of the interrupt lock? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443125420 From jpai at openjdk.org Fri Jan 5 17:25:24 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:25:24 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180: > 178: Thread me = Thread.currentThread(); > 179: if (me.isInterrupted()) { > 180: interruptor.interrupt(me); The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443147621 From jpai at openjdk.org Fri Jan 5 17:33:23 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:33:23 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 107: > 105: public void postInterrupt() { > 106: try { > 107: AbstractInterruptibleChannel.this.close(); Before the current change, the `Interruptible` implementation in this class used to call `AbstractInterruptibleChannel.this.implCloseChannel();` whereas now it calls `close()`. Is that an intentional change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443152626 From alanb at openjdk.org Fri Jan 5 17:33:26 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 17:33:26 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Fri, 5 Jan 2024 17:27:30 GMT, Jaikiran Pai wrote: >> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. > > src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 107: > >> 105: public void postInterrupt() { >> 106: try { >> 107: AbstractInterruptibleChannel.this.close(); > > Before the current change, the `Interruptible` implementation in this class used to call `AbstractInterruptibleChannel.this.implCloseChannel();` whereas now it calls `close()`. Is that an intentional change? Yes, this is intentional. > src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180: > >> 178: Thread me = Thread.currentThread(); >> 179: if (me.isInterrupted()) { >> 180: interruptor.interrupt(me); > > The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here. This is an internal interface, I can re-phrase the method description to make it clear that this is when Thread.interrupt is called. > src/java.base/share/classes/sun/nio/ch/Interruptible.java line 49: > >> 47: * Selector. This method is required to be idempotent. >> 48: */ >> 49: void postInterrupt(); > > Should there be any thread safety note/expectations on this method now that it can be potentially called concurrently by multiple threads since it's called outside of the interrupt lock? This is an internal interface, it's not a general purpose interface that anything outside of the NIO implementation should use. The phrase in the javadoc is meant to make it clear that it may be called more than once, and from several different I/O ops. on the channel. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443153433 PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443154022 PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443155765 From jpai at openjdk.org Fri Jan 5 17:37:24 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:37:24 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. src/java.base/share/classes/java/lang/VirtualThread.java line 863: > 861: checkAccess(); > 862: > 863: // if current thread is a virtual thread then prevent it from being Is the use of "current thread" here meant to imply "Thread.currentThread()"? If so, is there a check missing for `Thread.currentThread().isVirtual()` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443160966 From jpai at openjdk.org Fri Jan 5 17:50:22 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:50:22 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. These changes look OK to me. There are some trivial javadoc comments which you can decide if are worth doing - it's fine by me either way since like you note it is a tightly controlled internal interface. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17219#pullrequestreview-1806509423 From alanb at openjdk.org Fri Jan 5 17:50:25 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 17:50:25 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com> On Fri, 5 Jan 2024 17:35:01 GMT, Jaikiran Pai wrote: >> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. > > src/java.base/share/classes/java/lang/VirtualThread.java line 863: > >> 861: checkAccess(); >> 862: >> 863: // if current thread is a virtual thread then prevent it from being > > Is the use of "current thread" here meant to imply "Thread.currentThread()"? If so, is there a check missing for `Thread.currentThread().isVirtual()` here? It's correct. There are two threads, the current thread that is executing the method, plus "this". Serguei is working to change notifyJvmtiDisableSuspend to be a static method (JDK-8322744) to make it clearer that it disable suspend of the current virtual thread rather than the receiver. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443170217 From jpai at openjdk.org Fri Jan 5 17:50:27 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 5 Jan 2024 17:50:27 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com> References: <_6F0yVdYdkWjRGUTec6MES2uAdX149lvi72lcoAXfFU=.2b5833e8-b2c5-4901-be5b-f9472e504595@github.com> Message-ID: On Fri, 5 Jan 2024 17:42:42 GMT, Alan Bateman wrote: > Serguei is working to change notifyJvmtiDisableSuspend to be a static method (JDK-8322744) to make it clearer that it disable suspend of the current virtual thread rather than the receiver. That explains it then. Before commenting, I did check if `notifyJvmtiDisableSuspend` operates on the `Thread.currentThread()` but it was an instance method which ended up being a `native` method and I didn't dig deeper but assumed it works on the thread instance on which it is called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1443173235 From alanb at openjdk.org Fri Jan 5 18:27:21 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Jan 2024 18:27:21 GMT Subject: RFR: 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer [v2] In-Reply-To: References: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> Message-ID: On Fri, 5 Jan 2024 16:33:35 GMT, Brian Burkhalter wrote: >> Attempt to clarify when the values returned for a `FileStore`s usable and unallocated space are initialized and likely to be valid. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > Address reviewer comments Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17271#pullrequestreview-1806592578 From alanb at openjdk.org Sat Jan 6 08:55:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Jan 2024 08:55:30 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown [v2] In-Reply-To: <3ZjYlbhNYE9FX5bhyl2wLF_wbmPMDUbbzyq6ZKQJL-w=.7730ab17-3450-4faa-a43e-51e7a7285574@github.com> References: <3ZjYlbhNYE9FX5bhyl2wLF_wbmPMDUbbzyq6ZKQJL-w=.7730ab17-3450-4faa-a43e-51e7a7285574@github.com> Message-ID: On Fri, 5 Jan 2024 16:06:55 GMT, Jaikiran Pai wrote: > Given that these are unconnected DatagramChannels, do you think this test is susceptible to receiving unexpected packets (in CI environments) and can run into intermittent failures (receive completing successfully before being interrupted)? Would making them connected (to a test specific address that never sends anything) improve the situation or would that then take a different code path than what this test intends to test? I view the issue interference (stray datagrams) from other tests/programs as a separate topic. It would be useful to audit the DatagramChannel, DatagramSocket, and other tests that send unicast datagrams to identity the tests that send to target addresses/ports that the test doesn't control. Tests for PortUnreachableException or tests that need to use specific protocol families (IPv4 or IPv6) are examples. It sometimes feels like these need to be isolated, I don't think jtreg exclusivedirs provides enough as it's a lock file for a specific tree rather than all agent VMs. In addition, it would be a bit unusual to use send/receive on a connected DatagramChannel. It's allowed of course but usually it's read/write when connected. So I agree your suggestion is something we should consider doing, I view is as part of broader issue to reduce and eliminate interference from other programs or tests. This PR is more focused on fixing the timing issue in the test where a channel can be closed a nd the thread blocked on the channel interrupted at around the same time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17251#issuecomment-1879597678 From alanb at openjdk.org Sat Jan 6 08:55:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Jan 2024 08:55:31 GMT Subject: RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown [v2] In-Reply-To: References: Message-ID: On Thu, 4 Jan 2024 12:54:34 GMT, Alan Bateman wrote: >> InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. >> >> The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment in testInterruptDuringUninterruptibleReceive Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17251#issuecomment-1879597699 From alanb at openjdk.org Sat Jan 6 08:55:33 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Jan 2024 08:55:33 GMT Subject: Integrated: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 19:29:08 GMT, Alan Bateman wrote: > InterruptibleOrNot.testInterruptBeforeInterruptibleReceive has failed a few times. It calls DatagramChannel.receive with the interrupt status set and expects ClosedByInterruptException to be thrown. The shared part of the test is also used for the non-interruptible scenario which needs a delayed close to ensure the thread calling receive wakes up. The 2s delay is not sufficient and thus it's possible for the async close to beat the detection of the interrupt status. This leads to AsynchronousCloseException instead of the expected ClosedByInterruptException. > > The test is re-worked to split the interruptible and non-interruptible tests. The test is also changed to drop the delayed interrupt/close and instead use a thread to poll under the target thread is in DatagramChannel.receive. The overall test is simpler. I changed it to be a JUnit test, that part is only a few lines of changes. This pull request has now been integrated. Changeset: ace010b3 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/ace010b38a83e0c9b43aeeb6bc5c92d0886dc53f Stats: 161 lines in 1 file changed: 55 ins; 29 del; 77 mod 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown Reviewed-by: jpai, bpb ------------- PR: https://git.openjdk.org/jdk/pull/17251 From alanb at openjdk.org Mon Jan 8 09:04:57 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jan 2024 09:04:57 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock [v2] In-Reply-To: References: Message-ID: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. Alan Bateman 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: - Make sun.nio.ch.Interruptible's javadoc a bit clearer - Merge - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17219/files - new: https://git.openjdk.org/jdk/pull/17219/files/e402582d..634cd876 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17219&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17219&range=00-01 Stats: 4903 lines in 422 files changed: 2589 ins; 930 del; 1384 mod Patch: https://git.openjdk.org/jdk/pull/17219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17219/head:pull/17219 PR: https://git.openjdk.org/jdk/pull/17219 From alanb at openjdk.org Mon Jan 8 09:04:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Jan 2024 09:04:58 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock [v2] In-Reply-To: References: Message-ID: <2__yzgpgSnyrDV_DEY4c1wF3z35_nDvp7hAG99Acrow=.11c4d4db-8ce4-4c25-8948-d3f8b8177bdf@github.com> On Fri, 5 Jan 2024 17:28:30 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java line 180: >> >>> 178: Thread me = Thread.currentThread(); >>> 179: if (me.isInterrupted()) { >>> 180: interruptor.interrupt(me); >> >> The new javadoc comment on `Interruptor.interrupt(Thread)` states that "This method is invoked while holding the Thread's interrupt lock.", which isn't the case when being invoked from here. > > This is an internal interface, I can re-phrase the method description to make it clear that this is when Thread.interrupt is called. I've update the method descriptions in sun.nio.ch.Interruptible and hopefully it is a bit clearer now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17219#discussion_r1444309663 From jpai at openjdk.org Mon Jan 8 09:28:28 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 8 Jan 2024 09:28:28 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman wrote: >> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. > > Alan Bateman 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: > > - Make sun.nio.ch.Interruptible's javadoc a bit clearer > - Merge > - Merge > - Initial commit Thank you Alan for the updated javadoc. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17219#pullrequestreview-1808467345 From lancea at openjdk.org Mon Jan 8 17:41:21 2024 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 8 Jan 2024 17:41:21 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 18:51:08 GMT, Eirik Bj?rsn?s wrote: > This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. > > The fix is to update `Entry.readCEN` to read all 16 bits and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. > > The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. > > Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) @RealCLanger, can you add this to your list to review given your efforts to add support for Posix permission support? Eirik, I will try and make some time this week or early next for this one ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1881541762 From bpb at openjdk.org Mon Jan 8 21:20:23 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 8 Jan 2024 21:20:23 GMT Subject: RFR: 8321561: (fs) Add an API note to Files.move clarifying possible non-atomic behavior In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 16:29:26 GMT, Brian Burkhalter wrote: > Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/17061#issuecomment-1881835361 From alanb at openjdk.org Tue Jan 9 07:08:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Jan 2024 07:08:30 GMT Subject: Integrated: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock In-Reply-To: References: Message-ID: On Tue, 2 Jan 2024 10:21:11 GMT, Alan Bateman wrote: > In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. This pull request has now been integrated. Changeset: 7286f529 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/7286f5291d6aad290fda778668eeb3a7cbfd8a55 Stats: 143 lines in 6 files changed: 89 ins; 25 del; 29 mod 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/17219 From sspitsyn at openjdk.org Tue Jan 9 07:49:40 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 9 Jan 2024 07:49:40 GMT Subject: RFR: 8322829: Refactor nioBlocker to avoid blocking while holding Thread's interrupt lock [v2] In-Reply-To: References: Message-ID: On Mon, 8 Jan 2024 09:04:57 GMT, Alan Bateman wrote: >> In preparation for when virtual threads can unmount while holding a monitor or unmount when blocking on monitorenter, the implementation of VirtualThread's interrupt method is refactored to avoid parking/blocking while holding the Thread's interrupt lock. The implementations of sun.nio.ch.Interruptible are refactored to close/wakeup the InterruptibleChannel/Selector after releasing the interrupt lock. There is a lot of test coverage for async close and interrupt, no additional tests are added. > > Alan Bateman 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: > > - Make sun.nio.ch.Interruptible's javadoc a bit clearer > - Merge > - Merge > - Initial commit I see this has been already integrated. Just wanted to confirm that new JVMTI notifications look okay to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17219#issuecomment-1882555612 From eirbjo at openjdk.org Tue Jan 9 10:22:40 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 9 Jan 2024 10:22:40 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: > This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. > > The fix is to update `Entry.readCEN` to read all 16 bits and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. > > The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. > > Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) Eirik Bj?rsn?s 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: - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. - Merge branch 'master' into zipfs-preserve-external-file-attrs - Preserve non-permission 'external file attributes' bits when setting posix permissions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17170/files - new: https://git.openjdk.org/jdk/pull/17170/files/7f7771ee..524159f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=00-01 Stats: 3917 lines in 274 files changed: 2371 ins; 637 del; 909 mod Patch: https://git.openjdk.org/jdk/pull/17170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17170/head:pull/17170 PR: https://git.openjdk.org/jdk/pull/17170 From eirbjo at openjdk.org Tue Jan 9 10:26:23 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 9 Jan 2024 10:26:23 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s wrote: >> This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. >> >> The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. >> >> The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. >> >> Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) > > Eirik Bj?rsn?s 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: > > - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. > - Merge branch 'master' into zipfs-preserve-external-file-attrs > - Preserve non-permission 'external file attributes' bits when setting posix permissions Realizing that ANY read/sync operation (not just Files.setPosixPermissions) will cause 'external file attribute' bits to be discarded, I tweaked the test added to `PosixTests` to cover such cases. The added test case calls `Files.setLastModifiedTime` and verifies that the 'external file attribute' bits are not changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1882797964 From alanb at openjdk.org Tue Jan 9 14:45:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 9 Jan 2024 14:45:23 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s wrote: >> This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. >> >> The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. >> >> The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. >> >> Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) > > Eirik Bj?rsn?s 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: > > - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. > - Merge branch 'master' into zipfs-preserve-external-file-attrs > - Preserve non-permission 'external file attributes' bits when setting posix permissions I looked at the update to ZipFileSystem and the changes look right. I don't have time right now to look at the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1883176230 From clanger at openjdk.org Tue Jan 9 22:11:24 2024 From: clanger at openjdk.org (Christoph Langer) Date: Tue, 9 Jan 2024 22:11:24 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s wrote: >> This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. >> >> The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. >> >> The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. >> >> Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) > > Eirik Bj?rsn?s 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: > > - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. > - Merge branch 'master' into zipfs-preserve-external-file-attrs > - Preserve non-permission 'external file attributes' bits when setting posix permissions Looks correct to me, too. I also went over the changes to the test and it makes sense. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1812103908 From bpb at openjdk.org Wed Jan 10 02:02:26 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Jan 2024 02:02:26 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: <2ay5RhPgR1VhxGzq-4sj08XuQ5UpaUayhx4lqtq4MuQ=.e268d585-1fa8-4b71-9cbc-900337e5c34e@github.com> 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-1884071485 From eirbjo at openjdk.org Wed Jan 10 10:35:25 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 10:35:25 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 22:08:20 GMT, Christoph Langer wrote: >> Eirik Bj?rsn?s 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: >> >> - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. >> - Merge branch 'master' into zipfs-preserve-external-file-attrs >> - Preserve non-permission 'external file attributes' bits when setting posix permissions > > Looks correct to me, too. I also went over the changes to the test and it makes sense. Thanks to @RealCLanger for the review and to @AlanBateman for the nod. I'll let this linger a bit before integrating in case @LanceAndersen still wants to take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1884585790 From bpb at openjdk.org Wed Jan 10 16:37:29 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Jan 2024 16:37:29 GMT Subject: Integrated: 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer In-Reply-To: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> References: <41IWE7f64teiwd0Ih2WiCdthbrpF4lxRF50kFJne7vw=.50e8a30d-cb4f-4c03-b98f-444da44abc5c@github.com> Message-ID: On Thu, 4 Jan 2024 21:15:18 GMT, Brian Burkhalter wrote: > Attempt to clarify when the values returned for a `FileStore`s usable and unallocated space are initialized and likely to be valid. This pull request has now been integrated. Changeset: 475306b7 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/475306b7576356ca8e5b93fa7fe1be6c4d15065e Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 7057369: (fs spec) FileStore getUsableSpace and getUnallocatedSpace could be clearer Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17271 From lancea at openjdk.org Wed Jan 10 17:41:26 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 10 Jan 2024 17:41:26 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Tue, 9 Jan 2024 10:22:40 GMT, Eirik Bj?rsn?s wrote: >> This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. >> >> The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. >> >> The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. >> >> Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) > > Eirik Bj?rsn?s 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: > > - Verify that ZipFileSystem preserves 'external file attribute' bits when performing operations unrelated to POSIX, such as Files.setLastModifiedTime. > - Merge branch 'master' into zipfs-preserve-external-file-attrs > - Preserve non-permission 'external file attributes' bits when setting posix permissions Thank you for the PR. Overall it looks good a few couple nit comments. Extra credit to convert this from testng to a junit test but not a must test/jdk/jdk/nio/zipfs/TestPosix.java line 761: > 759: Files.write(zipFile, zip); > 760: > 761: // Verify that a read/synch roundtrip preserves the external file attributes typo 'synch' test/jdk/jdk/nio/zipfs/TestPosix.java line 770: > 768: > 769: // Verify calling Files.setPosixFilePermissions with current permission set > 770: try (FileSystem fs = FileSystems.newFileSystem(zipFile, ENV_POSIX)) { This should be a separate test IMHO ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1813747144 PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447701846 PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447718468 From eirbjo at openjdk.org Wed Jan 10 18:11:37 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 18:11:37 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v3] In-Reply-To: References: Message-ID: > This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. > > The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. > > The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. > > Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Extract testing of the Files.setPosixFilePermissions operation and the Files.setLastModifiedTime operation into separate test methods. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17170/files - new: https://git.openjdk.org/jdk/pull/17170/files/524159f3..e4a505fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=01-02 Stats: 53 lines in 1 file changed: 35 ins; 11 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17170/head:pull/17170 PR: https://git.openjdk.org/jdk/pull/17170 From eirbjo at openjdk.org Wed Jan 10 18:11:40 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 18:11:40 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen wrote: > Thank you for the PR. Overall it looks good a few couple nit comments. Thanks Lance, see e4a505fa073874824f247c20b76c3531a068ee32 for the latest update following your review. > test/jdk/jdk/nio/zipfs/TestPosix.java line 761: > >> 759: Files.write(zipFile, zip); >> 760: >> 761: // Verify that a read/synch roundtrip preserves the external file attributes > > typo 'synch' This comment was replaced with "Run the provided action on the ZipFileSystem" following the rewrite described below. > test/jdk/jdk/nio/zipfs/TestPosix.java line 770: > >> 768: >> 769: // Verify calling Files.setPosixFilePermissions with current permission set >> 770: try (FileSystem fs = FileSystems.newFileSystem(zipFile, ENV_POSIX)) { > > This should be a separate test IMHO I've separated two tests `setPermissionsShouldPreserveRemainingBits` and `setLastModifiedTimeShouldNotChangeExternalFileAttribute`, both using the support method `assertExternalFileAttributeUnchanged`. I agree this was much cleaner, since these are in fact separate and independent (but perhaps overlapping) issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885367252 PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447745607 PR Review Comment: https://git.openjdk.org/jdk/pull/17170#discussion_r1447747366 From eirbjo at openjdk.org Wed Jan 10 18:29:40 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 18:29:40 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v4] In-Reply-To: References: Message-ID: > This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. > > The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. > > The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. > > Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Convert TestPosix.java from testng to Junit 5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17170/files - new: https://git.openjdk.org/jdk/pull/17170/files/e4a505fa..885871f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17170&range=02-03 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/17170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17170/head:pull/17170 PR: https://git.openjdk.org/jdk/pull/17170 From eirbjo at openjdk.org Wed Jan 10 18:29:41 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 18:29:41 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v2] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen wrote: > Extra credit to convert this from testng to a junit test but not a must Challenge accepted, see 885871f for the conversion to JUnit 5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885395478 From bpb at openjdk.org Wed Jan 10 18:52:30 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 10 Jan 2024 18:52:30 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v7] In-Reply-To: References: Message-ID: <5CrlFoaHPXWGrGjiwwN2bMwWsZa8sr-I0OORJMsKp_8=.7a0021af-858d-4d8c-b216-cf2aed0eeed7@github.com> On Wed, 15 Nov 2023 01:41:53 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > 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 10 additional commits since the last revision: > > - 4860681: Fix java/nio/Buffer/CopyDirectMemory.java build failure > - Merge > - 4860681: Make test use RandomFactory > - Merge > - 4860681: Heap and direct buffer specializations > - 4860681: Change some {@code ...} to ... to prevent line breaking > - 4860681: Modify existing test > - Merge > - 4860681: Add spaces to parameter lists in @see tag > - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1885429754 From lancea at openjdk.org Wed Jan 10 21:29:25 2024 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 10 Jan 2024 21:29:25 GMT Subject: RFR: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits [v4] In-Reply-To: References: Message-ID: On Wed, 10 Jan 2024 18:29:40 GMT, Eirik Bj?rsn?s wrote: >> This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. >> >> The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. >> >> The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. >> >> Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Convert TestPosix.java from testng to Junit 5 Thank you for the updates. Looks good to go ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17170#pullrequestreview-1814209477 From eirbjo at openjdk.org Wed Jan 10 21:45:33 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 10 Jan 2024 21:45:33 GMT Subject: Integrated: 8322565 (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits In-Reply-To: References: Message-ID: On Wed, 20 Dec 2023 18:51:08 GMT, Eirik Bj?rsn?s wrote: > This PR suggests that `Files.setPosixPermissions`as implemented by `ZipFileSystem` should preserve the leading seven bits of the 'external file attributes' field. These bits contain the 'file type', 'setuid', 'setgid', and 'sticky' bits. These are unrelated to permissions and should not be modified by this operation. > > The fix is to update `Entry.readCEN` to read all 16 bits instead of just the trailing 12 and to update `ZipFileSystem.setPermissions` to preserve the leading 7 bits when updating the trailing 9 permission-related bits of the `Entry.posixPerms` field. > > The PR adds a new test `TestPosix.preserveRemainingBits()` which verifies that the leading 7 bits are not affected by `Files.setPosixPermissions`. This test also verifies that operations not related to POSIX, such as Files.setLastModifiedTime does not affect the 'external file attributes' value. > > Note that this PR does not aim to preserve the leading seven bits for the case when `Files.setPosixPermissions` is called with a `null` permission set. (The implementation currently interprets this as a signal that the 'external file attributes' should not be populated and the 'version made by' OS will be MSDOS instead of Unix) This pull request has now been integrated. Changeset: e70cb4e6 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/e70cb4e6c7fe131d585cfa3ff3b4dbeb4f9bbccd Stats: 145 lines in 2 files changed: 109 ins; 9 del; 27 mod 8322565: (zipfs) Files.setPosixPermissions should preserve 'external file attributes' bits Reviewed-by: clanger, lancea ------------- PR: https://git.openjdk.org/jdk/pull/17170 From tprinzing at openjdk.org Thu Jan 11 00:43:53 2024 From: tprinzing at openjdk.org (Tim Prinzing) Date: Thu, 11 Jan 2024 00:43:53 GMT Subject: RFR: 8310994: Add JFR event for selection operations [v4] In-Reply-To: References: Message-ID: > Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: comment fixup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16710/files - new: https://git.openjdk.org/jdk/pull/16710/files/13262293..18064cd1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710 From alanb at openjdk.org Thu Jan 11 14:57:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Jan 2024 14:57:23 GMT Subject: RFR: 8321561: (fs) Add an API note to Files.move clarifying possible non-atomic behavior In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 16:29:26 GMT, Brian Burkhalter wrote: > Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. src/java.base/share/classes/java/nio/file/Files.java line 1400: > 1398: * copying or renaming, then a {@code FileAlreadyExistsException} may be > 1399: * thrown despite the {@code REPLACE_EXISTING} option having been specified. > 1400: * I wonder if it might be better expand the description of REPLACE_EXISTING. That is, the existing paragraph could be expanded to say that if ATOMIC_MOVE is not specified then the checking the check for an existing file and the move is not atomic with respect to other filesystem activities. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1448982986 From bpb at openjdk.org Thu Jan 11 19:15:41 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 11 Jan 2024 19:15:41 GMT Subject: RFR: 8321561: (fs) Add an API note to Files.move clarifying possible non-atomic behavior [v2] In-Reply-To: References: Message-ID: > Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321561: Update verbiage instead of adding API note ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17061/files - new: https://git.openjdk.org/jdk/pull/17061/files/22d13f6c..ee6fbfcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17061&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17061&range=00-01 Stats: 18 lines in 1 file changed: 7 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17061/head:pull/17061 PR: https://git.openjdk.org/jdk/pull/17061 From bpb at openjdk.org Thu Jan 11 19:42:23 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 11 Jan 2024 19:42:23 GMT Subject: RFR: 8321561: (fs) Add an API note to Files.move clarifying possible non-atomic behavior [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 14:54:36 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8321561: Update verbiage instead of adding API note > > src/java.base/share/classes/java/nio/file/Files.java line 1400: > >> 1398: * copying or renaming, then a {@code FileAlreadyExistsException} may be >> 1399: * thrown despite the {@code REPLACE_EXISTING} option having been specified. >> 1400: * > > I wonder if it might be better expand the description of REPLACE_EXISTING. That is, the existing paragraph could be expanded to say that if ATOMIC_MOVE is not specified then the checking the check for an existing file and the move is not atomic with respect to other filesystem activities. Done in 22d13f6c29aaafa56b51e0f03c4469d7d2d25f6b. I put the verbiage after the options table as REPLACE_EXISTING is ignored if ATOMIC_MOVE is specified so it did not seem accurate to put the text in the row describing the former option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1449313687 From alanb at openjdk.org Fri Jan 12 11:44:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Jan 2024 11:44:22 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v2] In-Reply-To: References: Message-ID: <2vodjQyK9d2rGGj5LCMt5AtjZZCXk9IZecuYyA-5_-E=.24541078-b510-44df-b99b-eb5121108a93@github.com> On Thu, 11 Jan 2024 19:15:41 GMT, Brian Burkhalter wrote: >> Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8321561: Update verbiage instead of adding API note src/java.base/share/classes/java/nio/file/Files.java line 1363: > 1361: * If the {@code ATOMIC_MOVE} option is not specified, then the check for > 1362: * an existing file and the actual move might not be atomic with respect > 1363: * to other filesystem activities. This looks quite good. A small suggestion is to replace "the check for an existing file" with "the check if the target file exists". The reason is that the other sentences use the phrase "target file exists" a few times. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1450293699 From alanb at openjdk.org Fri Jan 12 12:13:21 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 12 Jan 2024 12:13:21 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v2] In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 19:15:41 GMT, Brian Burkhalter wrote: >> Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8321561: Update verbiage instead of adding API note src/java.base/share/classes/java/nio/file/Files.java line 1414: > 1412: * system operation, and a file is created at the target location > 1413: * between the existence check and actually moving the source > 1414: * (optional specific exceptions) I think it might be better to split into two sentences. The second sentence could be "It may also be thrown when the REPLACE_EXISTING option is specified, the move is not atomic, and the target file is created by some other entity at around the same time that this method is called". Would that work for you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1450349721 From bpb at openjdk.org Fri Jan 12 21:42:41 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Jan 2024 21:42:41 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v3] In-Reply-To: References: Message-ID: > Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8321561: Address Reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17061/files - new: https://git.openjdk.org/jdk/pull/17061/files/ee6fbfcb..06732ccb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17061&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17061&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17061/head:pull/17061 PR: https://git.openjdk.org/jdk/pull/17061 From bpb at openjdk.org Fri Jan 12 21:48:23 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 12 Jan 2024 21:48:23 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v2] In-Reply-To: <2vodjQyK9d2rGGj5LCMt5AtjZZCXk9IZecuYyA-5_-E=.24541078-b510-44df-b99b-eb5121108a93@github.com> References: <2vodjQyK9d2rGGj5LCMt5AtjZZCXk9IZecuYyA-5_-E=.24541078-b510-44df-b99b-eb5121108a93@github.com> Message-ID: On Fri, 12 Jan 2024 11:41:40 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8321561: Update verbiage instead of adding API note > > src/java.base/share/classes/java/nio/file/Files.java line 1363: > >> 1361: * If the {@code ATOMIC_MOVE} option is not specified, then the check for >> 1362: * an existing file and the actual move might not be atomic with respect >> 1363: * to other filesystem activities. > > This looks quite good. A small suggestion is to replace "the check for an existing file" with "the check if the target file exists". The reason is that the other sentences use the phrase "target file exists" a few times. Changed in 06732ccbdc4f0e39434eeee51b9a44c2d5a4b6b0. > src/java.base/share/classes/java/nio/file/Files.java line 1414: > >> 1412: * system operation, and a file is created at the target location >> 1413: * between the existence check and actually moving the source >> 1414: * (optional specific exceptions) > > I think it might be better to split into two sentences. The second sentence could be "It may also be thrown when the REPLACE_EXISTING option is specified, the move is not atomic, and the target file is created by some other entity at around the same time that this method is called". Would that work for you? So changed in 06732ccbdc4f0e39434eeee51b9a44c2d5a4b6b0. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1450953085 PR Review Comment: https://git.openjdk.org/jdk/pull/17061#discussion_r1450953128 From alanb at openjdk.org Sat Jan 13 07:26:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Jan 2024 07:26:22 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v3] In-Reply-To: References: Message-ID: <6yKFlo4iVxlA8ywsalOhO3rltL4KJmS9PPXQ5GiN-o0=.4380bb2d-6143-49fb-9244-03f3fe841fbd@github.com> On Fri, 12 Jan 2024 21:42:41 GMT, Brian Burkhalter wrote: >> Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8321561: Address Reviewer comments Marked as reviewed by alanb (Reviewer). Latest version looks good. I'll add myself as Reviewer to the CSR once it has sync'ed up with the current version. ------------- PR Review: https://git.openjdk.org/jdk/pull/17061#pullrequestreview-1819905088 PR Comment: https://git.openjdk.org/jdk/pull/17061#issuecomment-1890357143 From alanb at openjdk.org Sat Jan 13 15:01:45 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Jan 2024 15:01:45 GMT Subject: [jdk22] RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown Message-ID: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown ------------- Commit messages: - Backport ace010b38a83e0c9b43aeeb6bc5c92d0886dc53f Changes: https://git.openjdk.org/jdk22/pull/69/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=69&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319757 Stats: 161 lines in 1 file changed: 55 ins; 29 del; 77 mod Patch: https://git.openjdk.org/jdk22/pull/69.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/69/head:pull/69 PR: https://git.openjdk.org/jdk22/pull/69 From jpai at openjdk.org Sat Jan 13 15:15:21 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 13 Jan 2024 15:15:21 GMT Subject: [jdk22] RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown In-Reply-To: References: Message-ID: On Sat, 13 Jan 2024 14:46:56 GMT, Alan Bateman wrote: > 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown test-only change and a clean backport. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/69#pullrequestreview-1820031515 From alanb at openjdk.org Sat Jan 13 16:03:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Jan 2024 16:03:22 GMT Subject: [jdk22] RFR: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown In-Reply-To: References: Message-ID: On Sat, 13 Jan 2024 14:46:56 GMT, Alan Bateman wrote: > Test-only change, clean backport of JDK-8319757. Thanks for the quick review. ------------- PR Comment: https://git.openjdk.org/jdk22/pull/69#issuecomment-1890540636 From alanb at openjdk.org Sat Jan 13 16:03:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 13 Jan 2024 16:03:23 GMT Subject: [jdk22] Integrated: 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown In-Reply-To: References: Message-ID: On Sat, 13 Jan 2024 14:46:56 GMT, Alan Bateman wrote: > Test-only change, clean backport of JDK-8319757. This pull request has now been integrated. Changeset: 01f780fa Author: Alan Bateman URL: https://git.openjdk.org/jdk22/commit/01f780fab21aceed5f40baeb6d4fa832bfee8251 Stats: 161 lines in 1 file changed: 55 ins; 29 del; 77 mod 8319757: java/nio/channels/DatagramChannel/InterruptibleOrNot.java failed: wrong exception thrown Reviewed-by: jpai Backport-of: ace010b38a83e0c9b43aeeb6bc5c92d0886dc53f ------------- PR: https://git.openjdk.org/jdk22/pull/69 From simon at cjnash.com Sun Jan 14 23:54:47 2024 From: simon at cjnash.com (Simon Nash) Date: Sun, 14 Jan 2024 23:54:47 +0000 Subject: JDK-8321429 breaks FileKey.hashCode() Message-ID: <534650e9-9723-e609-de65-b577eb460579@cjnash.com> The change for JDK-8321429 breaks the hashCode() method of sun.nio.ch.FileKey. Before this change, the hashCode was computed from long values as follows: return (int)(dwVolumeSerialNumber ^ (dwVolumeSerialNumber >>> 32)) + (int)(nFileIndexHigh ^ (nFileIndexHigh >>> 32)) + (int)(nFileIndexLow ^ (nFileIndexLow >>> 32)); This adds the three 32-bit values for volumeSerialNumber, fileIndexHigh and fileIndexLow, producing a reasonable hash. With the change, the hashCode is computed from int values as follows: int h = dwVolumeSerialNumber; h = h << 31 + nFileIndexHigh; h = h << 31 + nFileIndexLow; return h; Because << has lower precedence than +, this shifts the serial number out of h twice and is very likely to return zero. My test results: serialNumber=0xc8b4b431 indexHigh=0x00240000 indexLow=0x00023be9 h=0x00000000 This should be reverted to the previous algorithm suitably adjusted to use the new int values: return dwVolumeSerialNumber + nFileIndexHigh + nFileIndexLow; Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jan 15 07:41:27 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Jan 2024 07:41:27 +0000 Subject: JDK-8321429 breaks FileKey.hashCode() In-Reply-To: <534650e9-9723-e609-de65-b577eb460579@cjnash.com> References: <534650e9-9723-e609-de65-b577eb460579@cjnash.com> Message-ID: On 14/01/2024 23:54, Simon Nash wrote: > The change for JDK-8321429 breaks the hashCode() method of > sun.nio.ch.FileKey. Well spotted, it means a poor hashCode when doing a lot of file locking on Windows.? I've created JDK-8323710 [1] to track it. -Alan [1] https://bugs.openjdk.org/browse/JDK-8323710 From alanb at openjdk.org Mon Jan 15 08:59:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Jan 2024 08:59:30 GMT Subject: RFR: 8323612: IOVecWrapper should be changed to be TerminatingThreadLocal Message-ID: Scatter/gather ops use a native iovec structure that is cached in a thread-local and registered with a Cleaner so it may be freed sometime after the thread has terminated. The change proposed here is to change it to a TerminatingThreadLocal so that it is freed when the thread terminates. In addition, to allow a virtual thread be preempted while it has a reference to iovec structure, IOVecWrapper.get is changed to "remove" the iovec from the cache, a new release method will re-add it to the cache. The changes mean this cache is consistent with the cache of direct buffers. The original plan was to also change IOVecWrapper but it somehow got forgotten. (The changes proposed here have been in the loom repo for some time. In the loom repo, preemption is possible when doing scatter/gather ops where the array of buffers includes heap buffers. More specifically, the iovec is obtained before substitution of heap buffers so it's possible that direct memory is exhausted and the thread has to wait for reference processing.) ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/17379/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323612 Stats: 42 lines in 2 files changed: 18 ins; 6 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/17379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17379/head:pull/17379 PR: https://git.openjdk.org/jdk/pull/17379 From bpb at openjdk.org Tue Jan 16 21:03:31 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Jan 2024 21:03:31 GMT Subject: RFR: 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) Message-ID: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> Dispense with the shift operators in calculating the hash code of `FileKey`. ------------- Commit messages: - 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) Changes: https://git.openjdk.org/jdk/pull/17452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323710 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17452/head:pull/17452 PR: https://git.openjdk.org/jdk/pull/17452 From alanb at openjdk.org Tue Jan 16 21:27:50 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Jan 2024 21:27:50 GMT Subject: RFR: 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) In-Reply-To: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> References: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> Message-ID: On Tue, 16 Jan 2024 20:56:21 GMT, Brian Burkhalter wrote: > Dispense with the shift operators in calculating the hash code of `FileKey`. Looks okay for now. At some point I think we should change the way that a FileKey is initialized so they can be final fields. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17452#pullrequestreview-1825134245 From brian.burkhalter at oracle.com Tue Jan 16 21:29:24 2024 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Jan 2024 21:29:24 +0000 Subject: JDK-8321429 breaks FileKey.hashCode() In-Reply-To: References: <534650e9-9723-e609-de65-b577eb460579@cjnash.com> Message-ID: A fix proposal has been opened: https://github.com/openjdk/jdk/pull/17452. Brian On Jan 14, 2024, at 11:41 PM, Alan Bateman > wrote: On 14/01/2024 23:54, Simon Nash wrote: The change for JDK-8321429 breaks the hashCode() method of sun.nio.ch.FileKey. Well spotted, it means a poor hashCode when doing a lot of file locking on Windows. I've created JDK-8323710 [1] to track it. -Alan [1] https://bugs.openjdk.org/browse/JDK-8323710 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue Jan 16 22:35:49 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Jan 2024 22:35:49 GMT Subject: RFR: 8323612: IOVecWrapper should be changed to be TerminatingThreadLocal In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 19:36:59 GMT, Alan Bateman wrote: > Scatter/gather ops use a native iovec structure that is cached in a thread-local and registered with a Cleaner so it may be freed sometime after the thread has terminated. The change proposed here is to change it to a TerminatingThreadLocal so that it is freed when the thread terminates. In addition, to allow a virtual thread be preempted while it has a reference to iovec structure, IOVecWrapper.get is changed to "remove" the iovec from the cache, a new release method will re-add it to the cache. The changes mean this cache is consistent with the cache of direct buffers. The original plan was to also change IOVecWrapper but it somehow got forgotten. > > (The changes proposed here have been in the loom repo for some time. In the loom repo, preemption is possible when doing scatter/gather ops where the array of buffers includes heap buffers. More specifically, the iovec is obtained before substitution of heap buffers so it's possible that direct memory is exhausted and the thread has to wait for reference processing.) Looks okay to me. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17379#pullrequestreview-1825459476 From bpb at openjdk.org Tue Jan 16 22:36:53 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 16 Jan 2024 22:36:53 GMT Subject: RFR: 8321561: (fs) Clarify non-atomic behavior of Files.move [v3] In-Reply-To: <6yKFlo4iVxlA8ywsalOhO3rltL4KJmS9PPXQ5GiN-o0=.4380bb2d-6143-49fb-9244-03f3fe841fbd@github.com> References: <6yKFlo4iVxlA8ywsalOhO3rltL4KJmS9PPXQ5GiN-o0=.4380bb2d-6143-49fb-9244-03f3fe841fbd@github.com> Message-ID: On Sat, 13 Jan 2024 07:23:42 GMT, Alan Bateman wrote: > [...] the CSR once it has sync'ed up with the current version. Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17061#issuecomment-1894629589 From duke at openjdk.org Wed Jan 17 02:46:50 2024 From: duke at openjdk.org (yaqsun) Date: Wed, 17 Jan 2024 02:46:50 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). I search testcases about grep "Files.createTempFile" ./test/jdk -R, and test. Only java/nio/file/Files/CopyMoveVariations.java fail, so the method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. $ jtreg/bin/jtreg -dir:test/jdk -nativepath:./native-jdk/jdk/jtreg/native -verbose:fail,error,summary -testjdk:./x64-release-jdk jdk/jfr/threading/TestManyVirtualThreads.java jdk/jfr/api/consumer/filestream/TestOrdered.java jdk/jfr/api/consumer/filestream/TestReuse.java jdk/nio/zipfs/ZeroDate.java jdk/nio/zipfs/UpdateEntryTest.java tools/jlink/plugins/GenerateJLIClassesPluginTest.java tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java tools/jimage/JImageListTest.java tools/jimage/JImageExtractTest.java tools/jimage/JImageVerifyTest.java com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java java/util/zip/ZipFile/ZeroDate.java java/util/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java java/util/Properties/PropertiesStoreTest.java java/util/Properties/StoreReproducibilityTest.java java/io/FileInputStream/NegativeAvailable.java java/io/File/LastModifiedTest.java java/io/File/GetXSpace.java java/io/File/TempDirDoesNotExist.java java/io/PrintStream/Faili ngConstructors.java java/io/ByteArrayInputStream/ChunkedTransferTo.java java/nio/file/WatchService/UpdateInterference.java java/nio/file/etc/MacVolumesTest.java java/nio/file/Files/DeleteOnClose.java java/nio/file/Files/CopyToNonDefaultFS.java java/nio/file/Files/TemporaryFiles.java java/nio/file/Files/StreamLinesTest.java java/nio/file/Files/CopyInterference.java java/nio/file/Files/StreamTest.java java/nio/file/Files/CallWithInterruptSet.java java/nio/file/Files/BytesAndLines.java java/nio/file/Files/SubstDrive.java java/nio/file/Files/CopyMoveVariations.java java/nio/file/Files/probeContentType/Basic.java java/nio/file/Files/probeContentType/ParallelProbes.java java/nio/file/attribute/PosixFileAttributeView/Basic.java java/nio/file/Path/MacToRealPathWithSM.java java/nio/MappedByteBuffer/Force.java java/nio/channels/FileChannel/MapWithSecurityManager.java java/nio/channels/FileChannel/directio/DirectIOTest.java java/nio/channels/FileChannel/LargeGatheringWrite.java java/nio/channe ls/FileChannel/Transfer2GPlus.java java/nio/channels/FileChannel/CloseDuringTransfer.java java/nio/channels/FileChannel/TempDirectBuffersReclamation.java java/nio/channels/FileChannel/Position.java java/nio/channels/FileChannel/TransferToAppending.java java/nio/channels/FileChannel/TransferFromExtend.java java/nio/channels/FileChannel/Transfer4GBFile.java java/nio/channels/FileChannel/LoopingTruncate.java java/nio/channels/FileLock/Overlaps.java java/nio/channels/Channels/TransferTo.java java/lang/String/NoReplTest.java java/lang/module/ModuleFinderTest.java java/lang/management/BufferPoolMXBean/Basic.java java/lang/StackTraceElement/SerialTest.java java/net/httpclient/security/Driver.java java/net/httpclient/SmokeTest.java javax/sound/sampled/spi/AudioFileReader/ShortHeader.java javax/sound/sampled/spi/AudioFileReader/AudioFileClose.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating Passed: com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java Passed: java/io/ByteArrayInputStream/ChunkedTransferTo.java Passed: java/io/File/GetXSpace.java Passed: java/io/File/LastModifiedTest.java Passed: java/io/File/TempDirDoesNotExist.java Passed: java/io/FileInputStream/NegativeAvailable.java Passed: java/io/PrintStream/FailingConstructors.java Passed: java/lang/management/BufferPoolMXBean/Basic.java Passed: java/lang/module/ModuleFinderTest.java Passed: java/lang/StackTraceElement/SerialTest.java Passed: java/lang/String/NoReplTest.java Passed: java/net/httpclient/security/Driver.java Passed: java/net/httpclient/SmokeTest.java Passed: java/nio/channels/Channels/TransferTo.java Passed: java/nio/channels/FileChannel/CloseDuringTransfer.java Passed: java/nio/channels/FileChannel/directio/DirectIOTest.java Passed: java/nio/channels/FileChannel/LargeGatheringWrite.java Passed: java/nio/channels/FileChannel/LoopingTruncate.java Passed: java/nio/channels/FileChannel/MapWithSecurityManager.java Passed: java/nio/channels/FileChannel/Position.java Passed: java/nio/channels/FileChannel/TempDirectBuffersReclamation.java Passed: java/nio/channels/FileChannel/Transfer2GPlus.java Passed: java/nio/channels/FileChannel/Transfer4GBFile.java Passed: java/nio/channels/FileChannel/TransferFromExtend.java Passed: java/nio/channels/FileChannel/TransferToAppending.java Passed: java/nio/channels/FileLock/Overlaps.java Passed: java/nio/file/attribute/PosixFileAttributeView/Basic.java Passed: java/nio/file/Files/BytesAndLines.java Passed: java/nio/file/Files/CallWithInterruptSet.java Passed: java/nio/file/Files/CopyInterference.java -------------------------------------------------- Failed: java/nio/file/Files/CopyMoveVariations.java Passed: java/nio/file/Files/CopyToNonDefaultFS.java Passed: java/nio/file/Files/DeleteOnClose.java Passed: java/nio/file/Files/probeContentType/Basic.java Passed: java/nio/file/Files/probeContentType/ParallelProbes.java Passed: java/nio/file/Files/StreamLinesTest.java Passed: java/nio/file/Files/StreamTest.java Passed: java/nio/file/Files/TemporaryFiles.java Passed: java/nio/file/WatchService/UpdateInterference.java Passed: java/nio/MappedByteBuffer/Force.java Passed: java/util/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java Passed: java/util/Properties/PropertiesStoreTest.java Passed: java/util/Properties/StoreReproducibilityTest.java Passed: java/util/zip/ZipFile/ZeroDate.java Passed: javax/sound/sampled/spi/AudioFileReader/AudioFileClose.java Passed: javax/sound/sampled/spi/AudioFileReader/ShortHeader.java Passed: jdk/jfr/api/consumer/filestream/TestOrdered.java Passed: jdk/jfr/api/consumer/filestream/TestReuse.java Passed: jdk/jfr/threading/TestManyVirtualThreads.java Passed: jdk/nio/zipfs/UpdateEntryTest.java Passed: jdk/nio/zipfs/ZeroDate.java Passed: tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java Passed: tools/jimage/JImageExtractTest.java Passed: tools/jimage/JImageListTest.java Passed: tools/jimage/JImageVerifyTest.java Passed: tools/jlink/plugins/GenerateJLIClassesPluginTest.java Test results: passed: 55; failed: 1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1894847126 From alanb at openjdk.org Wed Jan 17 10:58:58 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Jan 2024 10:58:58 GMT Subject: Integrated: 8323612: IOVecWrapper should be changed to be TerminatingThreadLocal In-Reply-To: References: Message-ID: On Thu, 11 Jan 2024 19:36:59 GMT, Alan Bateman wrote: > Scatter/gather ops use a native iovec structure that is cached in a thread-local and registered with a Cleaner so it may be freed sometime after the thread has terminated. The change proposed here is to change it to a TerminatingThreadLocal so that it is freed when the thread terminates. In addition, to allow a virtual thread be preempted while it has a reference to iovec structure, IOVecWrapper.get is changed to "remove" the iovec from the cache, a new release method will re-add it to the cache. The changes mean this cache is consistent with the cache of direct buffers. The original plan was to also change IOVecWrapper but it somehow got forgotten. > > (The changes proposed here have been in the loom repo for some time. In the loom repo, preemption is possible when doing scatter/gather ops where the array of buffers includes heap buffers. More specifically, the iovec is obtained before substitution of heap buffers so it's possible that direct memory is exhausted and the thread has to wait for reference processing.) This pull request has now been integrated. Changeset: b8dafa64 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/b8dafa642e6c401039d7561f562c98d46e34e5ab Stats: 42 lines in 2 files changed: 18 ins; 6 del; 18 mod 8323612: IOVecWrapper should be changed to be TerminatingThreadLocal Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/17379 From bpb at openjdk.org Wed Jan 17 16:38:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Jan 2024 16:38:02 GMT Subject: Integrated: 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) In-Reply-To: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> References: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> Message-ID: On Tue, 16 Jan 2024 20:56:21 GMT, Brian Burkhalter wrote: > Dispense with the shift operators in calculating the hash code of `FileKey`. This pull request has now been integrated. Changeset: 4e532353 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/4e5323538c81f6ca525e7681841d09f2ddf408b9 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17452 From bpb at openjdk.org Wed Jan 17 16:38:02 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Jan 2024 16:38:02 GMT Subject: Integrated: 8321561: (fs) Clarify non-atomic behavior of Files.move In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 16:29:26 GMT, Brian Burkhalter wrote: > Make it clear that a `FileAlreadyExistsException` may be thrown by `Files.move` even if the `REPLACE_EXISTING` option is specified. This pull request has now been integrated. Changeset: 19287eee Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/19287eeeb2c10ea5562c2fe43d8bd16814ddf8dd Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8321561: (fs) Clarify non-atomic behavior of Files.move Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17061 From bpb at openjdk.org Wed Jan 17 18:48:56 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 17 Jan 2024 18:48:56 GMT Subject: RFR: 8323710: (fc) FileChannel.lock creates a FileKey with a poor hashCode after JDK-8321429 (win) In-Reply-To: References: <0ZVbu7z-xpzZr4yNf_gzQo_suBLEIrGxozvNIxWxtL8=.99dd3e03-001b-4df5-8f78-643d020a2b51@github.com> Message-ID: On Tue, 16 Jan 2024 21:25:11 GMT, Alan Bateman wrote: > At some point I think we should change the way that a FileKey is initialized so they can be final fields. Please see https://bugs.openjdk.org/browse/JDK-8324048. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17452#issuecomment-1896434404 From prappo at openjdk.org Wed Jan 17 21:26:02 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 17 Jan 2024 21:26:02 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base Message-ID: Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/17468/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17468&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324053 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17468/head:pull/17468 PR: https://git.openjdk.org/jdk/pull/17468 From naoto at openjdk.org Wed Jan 17 22:59:51 2024 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 17 Jan 2024 22:59:51 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828357538 From darcy at openjdk.org Wed Jan 17 23:12:49 2024 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 17 Jan 2024 23:12:49 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828378857 From ihse at openjdk.org Thu Jan 18 09:32:15 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 18 Jan 2024 09:32:15 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. Thanks! When this has been integrated, I can take a shot at the missorted `default`s. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829238473 From dfuchs at openjdk.org Thu Jan 18 09:49:13 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 18 Jan 2024 09:49:13 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: <_1D6S_orn-H9wHL41PEskm8JN2PLJs_GvkxIg-Ht0Zs=.b3db368a-ee61-4951-b143-f49fb9e1f702@github.com> On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829273407 From prappo at openjdk.org Thu Jan 18 10:04:14 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 18 Jan 2024 10:04:14 GMT Subject: RFR: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Thu, 18 Jan 2024 09:29:11 GMT, Magnus Ihse Bursie wrote: > Thanks! When this has been integrated, I can take a shot at the missorted `default`s. Thanks, I could've done that myself, but decided not to. You see, `default` should ideally be a [sole] modifier on a method: all other modifiers of a `default` method should be deleted. I'm not sure that reaching such an ideal would be welcomed. Whatever you decide to do, be prepared to work manually. `bin/blessed-modifier-order.sh` is simple and robust but not specific. You'll have to carefully sift through other missortings it finds. [sole]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117398.html ------------- PR Comment: https://git.openjdk.org/jdk/pull/17468#issuecomment-1898162068 From prappo at openjdk.org Thu Jan 18 22:31:38 2024 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 18 Jan 2024 22:31:38 GMT Subject: Integrated: 8324053: Use the blessed modifier order for sealed in java.base In-Reply-To: References: Message-ID: On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo wrote: > Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396. This pull request has now been integrated. Changeset: 9efdd242 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/9efdd242fb40a8270e489cc071ff1c891878e24f Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod 8324053: Use the blessed modifier order for sealed in java.base Reviewed-by: naoto, darcy, ihse, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/17468 From duke at openjdk.org Tue Jan 23 09:59:38 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Jan 2024 09:59:38 GMT Subject: Withdrawn: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote: > See the JBS issue for an extended problem description. > > This patch changes the specification and implementation of `MethodHandles::byteArrayViewVarHandle`, `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and `ByteBuffer::alignmentOffset` to weaken the guarantees they make about the alignment of Java array elements, in order to bring them in line with the guarantees made by an arbitrary JVM implementation (which makes no guarantees about array element alignment beyond them being aligned to their natural alignment). > > - `MethodHandles::byteArrayViewVarHandle`: we can not guarantee any alignment for the accesses. Which means we can only reliably support plain get and set access modes. The javadoc text explaining which other access modes are supported, or how to compute aligned offsets into the array is dropped, as it is not guaranteed to be correct on all JVM implementations. The implementation of the returned VarHandle is changed to throw an `UnsupportedOperationException` for the unsupported access modes, as mandated by the spec of `VarHandle` [1]. > > - `MethodHandles::byteBufferViewVarHandle`: the implementation/spec is incorrect when accessing a heap buffer (wrapping a byte[]), for the same reasons as `byteArrayViewVarHandle`. The spec is changed to specify that when accessing a _heap buffer_, only plain get and set access modes are supported. The implementation of the returned var handle is changed to throw an `IllegalStateException` when an access is attempted on a heap buffer using an access mode other than plain get or set. Note that we don't throw an outright `UnsupportedOperationException` for this case, since whether the access modes are supported depends on the byte buffer instance being used. > > - `ByteBuffer::alignedSlice` and `ByteBuffer::alignmentOffset`: The former method depends directly on the latter for all its alignment computations. We change the implementation of the latter method to throw an `UnsupportedOperationException` for all unit sizes greater than 1, when the buffer is non-direct. This change is largely covered by the existing specification: > > > * @throws UnsupportedOperationException > * If the native platform does not guarantee stable alignment offset > * values for the given unit size when managing the memory regions > * of buffers of the same kind as this buffer (direct or > * non-direct). For example, if garbage collection would result > * in the mo... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16681 From liach at openjdk.org Tue Jan 23 14:46:36 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jan 2024 14:46:36 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... Also curious, is there any documentation (like JVMS) that allows JVMs to make no offset into byte arrays aligned for larger access? Would be helpful if we can have a reference here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1906200196 From liach at openjdk.org Tue Jan 23 14:46:39 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jan 2024 14:46:39 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 18:10:28 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4518: >> >>> 4516: * Only plain {@linkplain VarHandle.AccessMode#GET get} and {@linkplain VarHandle.AccessMode#SET set} >>> 4517: * access modes are supported by the returned var handle. For all other access modes, an >>> 4518: * {@link UnsupportedOperationException} will be thrown. >> >> I recommend adding an api note explaining that native memory segments, direct byte buffers, or heap memory segments backed by long[] should be used if support for other access modes are required. > > Good idea. Thanks Should we make these unaligned access modes throw ISE like before, when the given index is unaligned? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463367572 From jvernee at openjdk.org Tue Jan 23 18:27:31 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 23 Jan 2024 18:27:31 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com> On Tue, 23 Jan 2024 14:30:08 GMT, Chen Liang wrote: >> Good idea. Thanks > > Should we make these unaligned access modes throw ISE like before, when the given index is unaligned? You mean `get` and `set`? They should never throw, as unaligned access is fine. For other access modes, we can never guarantee that an access is aligned, so UOE is appropriate. (IIRC this is mandated by existing spec. I'll try to find it again) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463769755 From jvernee at openjdk.org Tue Jan 23 18:40:30 2024 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 23 Jan 2024 18:40:30 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: References: Message-ID: On Tue, 23 Jan 2024 14:43:24 GMT, Chen Liang wrote: > Also curious, is there any documentation (like JVMS) that allows JVMs to make no offset into byte arrays aligned for larger access? Would be helpful if we can have a reference here. There is simply no guarantee in the JVMS that array elements are aligned more than their size. So, the public API may not assume that they are, since it needs to be implementable by an arbitrary JVM that is JVMS compliant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16681#issuecomment-1906687425 From liach at openjdk.org Tue Jan 23 20:35:29 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Jan 2024 20:35:29 GMT Subject: RFR: 8318966: Some methods make promises about Java array element alignment that are too strong In-Reply-To: <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com> References: <8DFnNb3KsE4jKM-Aaln4A8tKaJpXmDWfvEODAKXQD2I=.246523c3-6a11-4d9e-9ae7-6db0117aa5ea@github.com> Message-ID: On Tue, 23 Jan 2024 18:24:59 GMT, Jorn Vernee wrote: >> Should we make these unaligned access modes throw ISE like before, when the given index is unaligned? > > You mean `get` and `set`? They should never throw, as unaligned access is fine. For other access modes, we can never guarantee that an access is aligned, so UOE is appropriate. (IIRC this is mandated by existing spec. I'll try to find it again) > > P.S. See e.g. the javadoc of `VarHandle::getVolatile`: > >> @throws UnsupportedOperationException if the access mode is unsupported for this VarHandle. > > P.P.S. Also remembering that we can not have any implementation for the access methods, in order for `isAccessModeSupported` to work correctly. And the logic that handles unsupported methods throws UOE (see `VarForm::getMemberName`) Good point, so previous behavior of throwing ISE is out of spec ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16681#discussion_r1463958704 From eirbjo at openjdk.org Wed Jan 24 15:49:34 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 24 Jan 2024 15:49:34 GMT Subject: RFR: 8324635: (zipfs) Regression in Files.setPosixFilePermissions called on existing MSDOS entries Message-ID: <4-JvAWwMDyx-5tMy_qnVwOE3zdUZITFo4-LR-Ascmrc=.0eb713b7-07c3-4884-af42-401ecce11325@github.com> 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). ------------- Commit messages: - If the entry currently has no permissions set, don't try to merge permission bits with existing -1 bits Changes: https://git.openjdk.org/jdk/pull/17556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324635 Stats: 31 lines in 2 files changed: 29 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 syan at openjdk.org Sun Jan 28 16:05:41 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 28 Jan 2024 16:05:41 GMT Subject: RFR: 8322881: [TESTBUG]java/nio/file/Files/CopyMoveVariations.java fails when run with non-root user Message-ID: 8322881: [TESTBUG]java/nio/file/Files/CopyMoveVariations.java fails when run with non-root user ------------- Commit messages: - 8322881: [TESTBUG]java/nio/file/Files/CopyMoveVariations.java fails when run with non-root user Changes: https://git.openjdk.org/jdk/pull/17606/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17606&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322881 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17606.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17606/head:pull/17606 PR: https://git.openjdk.org/jdk/pull/17606 From syan at openjdk.org Sun Jan 28 16:13:33 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 28 Jan 2024 16:13:33 GMT Subject: RFR: 8322881: [TESTBUG]java/nio/file/Files/CopyMoveVariations.java fails when run with non-root user In-Reply-To: References: Message-ID: <25Uyft6SVvxKhZaMOQCBqfvX0urA794NpByvk9OV-Ik=.69173fe6-0954-40b6-a339-e9c657ddc214@github.com> On Sun, 28 Jan 2024 15:59:26 GMT, SendaoYan wrote: > 8322881: [TESTBUG]java/nio/file/Files/CopyMoveVariations.java fails when run with non-root user Before this PR, this testcase run fail with non-root user. I think the testcase author run this testcase with root user or privilege users. I think it's necessary to make tests run pass with non-root users. When run this test case with root user, it will not cause java.nio.file.AccessDeniedException in any cases, do the test case bug will not expose. Before the patch apply, the testcase run fail with non-root user: ![image](https://github.com/openjdk/jdk/assets/24123821/a02ad085-6180-4edd-a16b-37a98bf9f88f) After the patch apply, the testcase run pass with non-root user: ![image](https://github.com/openjdk/jdk/assets/24123821/992d12d3-640d-49b7-bac6-3226682384b3) ------------- PR Comment: https://git.openjdk.org/jdk/pull/17606#issuecomment-1913646775 From syan at openjdk.org Sun Jan 28 16:18:34 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 28 Jan 2024 16:18:34 GMT Subject: RFR: 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp In-Reply-To: References: Message-ID: On Wed, 3 Jan 2024 03:42:17 GMT, yaqsun wrote: > testcase: java/nio/file/Files/CopyMoveVariations.java > > Method createTempFile() creates "/tmp/file*" that it causes file copy permission issue when running through jtreg. > > The method call `Files.move(source, target, options)` by Regular User causes AccessDeniedException due to ` /tmp/file*` is created when running through jtreg. > > Create files for method "createTempFile()" passing in the current path(jtreg_test_jdk_java_nio_file_Files_CopyMoveVariations_java/scratch or JTwork/scratch). Another solution: https://github.com/openjdk/jdk/pull/17606 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17235#issuecomment-1913648700 From jpai at openjdk.org Tue Jan 30 19:33:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Jan 2024 19:33:10 GMT Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo Message-ID: Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine. ------------- Commit messages: - 8271147: java/nio/file/Path.java javadoc typo Changes: https://git.openjdk.org/jdk/pull/4884/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8271147 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/4884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/4884/head:pull/4884 PR: https://git.openjdk.org/jdk/pull/4884 From iris at openjdk.org Tue Jan 30 19:33:10 2024 From: iris at openjdk.org (Iris Clark) Date: Tue, 30 Jan 2024 19:33:10 GMT Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/4884#pullrequestreview-713382247 From jpai at openjdk.org Tue Jan 30 19:33:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Jan 2024 19:33:10 GMT Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine. Thank you for the review, Iris. ------------- PR Comment: https://git.openjdk.org/jdk/pull/4884#issuecomment-885383972 From jpai at openjdk.org Tue Jan 30 19:33:10 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 30 Jan 2024 19:33:10 GMT Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine. This pull request has now been integrated. Changeset: 8156ff60 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/8156ff609b27316f31ba89d9eb8ca752f4027c2b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8271147: java/nio/file/Path.java javadoc typo Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk/pull/4884 From bpb at openjdk.org Tue Jan 30 20:05:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 30 Jan 2024 20:05:40 GMT Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v2] In-Reply-To: References: Message-ID: On Mon, 20 Nov 2023 23:30:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`. > > 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 three additional commits since the last revision: > > - 8298318: Correct type in path.getExtension spec > - Merge > - 8298318: (fs) APIs for handling filename extensions continue; ------------- PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-1917795966 From mdoerr at openjdk.org Wed Jan 31 06:11:08 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 31 Jan 2024 06:11:08 GMT Subject: RFR: 8324539: Do not use LFS64 symbols in JDK libs In-Reply-To: References: <4Pd7oVMUE2HYXJtde1fxURXSaS24X2bK5t2448kwT8s=.8a8c6fbc-3537-4289-8577-a978636f55a2@github.com> Message-ID: On Tue, 30 Jan 2024 14:02:41 GMT, Matthias Baesken wrote: >>> Yes there is a nice define in the AIX header >> >> *sigh* On linux, they go to some lengths to avoid this, using a __REDEFINE mechanism. Oh well. >> >> Anyway, I think this particular can be resolved by not including the standard includes in the header file (which is bad practice anyway!). I'm currently testing this build in our CI to see that it does not break anything else. I'd appreciate if you could take the latest version for a spin, particularly a debug build... > >> I'd appreciate if you could take the latest version for a spin, particularly a debug build... > > Yes we pick up the latest version of the PR in a couple of hours for the build+'lots of tests' (and this includes a fastdebug too). @MBaesken, @JoKern65: This seems to break the debug build (fast and slow) on AIX: jdk/src/java.desktop/share/native/libawt/java2d/pipe/BufferedRenderPipe.c:101:24: error: no member named 'open64' in 'SpanIteratorFuncs'; did you mean 'open'? srData = (*pFuncs->open)(env, si); ^~~~ open /usr/include/fcntl.h:115:14: note: expanded from macro 'open' #define open open64 ^ jdk/src/java.desktop/share/native/libawt/java2d/pipe/SpanIterator.h:37:17: note: 'open' declared here void *(*open)(JNIEnv *env, jobject iterator); ^ Ah, that has already been reported above. Yeah, interesting that the normal build has passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918443702 From pminborg at openjdk.org Wed Jan 31 08:45:08 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 31 Jan 2024 08:45:08 GMT Subject: RFR: 8324972: Potential thread safety issue in DirectByteBuffer.Deallocator that could lead to unspecified runtime behaviour Message-ID: This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. Passes tier1, 2, and 3 tests. ------------- Commit messages: - Make deallocators and unmappers idempotent Changes: https://git.openjdk.org/jdk/pull/17647/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324972 Stats: 35 lines in 2 files changed: 15 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/17647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17647/head:pull/17647 PR: https://git.openjdk.org/jdk/pull/17647 From alanb at openjdk.org Wed Jan 31 09:00:08 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 31 Jan 2024 09:00:08 GMT Subject: RFR: 8324972: Potential thread safety issue in DirectByteBuffer.Deallocator that could lead to unspecified runtime behaviour In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 08:41:05 GMT, Per Minborg wrote: > This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. > > There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. > > Passes tier1, 2, and 3 tests. I'm busy this week but I will reply to this PR next week. I don't object to making it idempotent but I have concerns with using AtomicBoolean and it pulling in MH/VH classes. It very important that we have as few dependences as possible in this area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17647#issuecomment-1918661840 From mbaesken at openjdk.org Wed Jan 31 09:22:07 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 31 Jan 2024 09:22: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 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 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1918699480 From pminborg at openjdk.org Wed Jan 31 09:50:57 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 31 Jan 2024 09:50:57 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v2] In-Reply-To: References: Message-ID: > This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. > > There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. > > Passes tier1, 2, and 3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Refrain from using AtomicBoolean ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17647/files - new: https://git.openjdk.org/jdk/pull/17647/files/f735bc9d..3177c1ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=00-01 Stats: 18 lines in 1 file changed: 13 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17647/head:pull/17647 PR: https://git.openjdk.org/jdk/pull/17647 From pminborg at openjdk.org Wed Jan 31 09:54:02 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 31 Jan 2024 09:54:02 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:50:57 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Refrain from using AtomicBoolean src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 81: > 79: private static final class Deallocator implements Runnable { > 80: > 81: private static final AtomicIntegerFieldUpdater UPDATER = It would be possible to use `Unsafe` directly instead of AIFU. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1472569573 From shade at openjdk.org Wed Jan 31 12:52:01 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 31 Jan 2024 12:52:01 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v2] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 09:51:22 GMT, Per Minborg wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Refrain from using AtomicBoolean > > src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 81: > >> 79: private static final class Deallocator implements Runnable { >> 80: >> 81: private static final AtomicIntegerFieldUpdater UPDATER = > > It would be possible to use `Unsafe` directly instead of AIFU. +1, just use `Unsafe` directly here. `AIFU` would probably even worse than `AtomicInteger` if we want to minimize dependencies. We already use Unsafe in adjacent classes here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1472777492 From pminborg at openjdk.org Wed Jan 31 16:44:17 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 31 Jan 2024 16:44:17 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: > This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. > > There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. > > Passes tier1, 2, and 3 tests. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Swith to using Unsafe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17647/files - new: https://git.openjdk.org/jdk/pull/17647/files/3177c1ed..21fcd8cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17647&range=01-02 Stats: 12 lines in 2 files changed: 1 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17647.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17647/head:pull/17647 PR: https://git.openjdk.org/jdk/pull/17647 From shade at openjdk.org Wed Jan 31 16:47:02 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 31 Jan 2024 16:47:02 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 16:44:17 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Swith to using Unsafe src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 50: > 48: import java.nio.channels.WritableByteChannel; > 49: import java.util.Objects; > 50: import java.util.concurrent.atomic.AtomicIntegerFieldUpdater; Unused import? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1473139220 From msheppar at openjdk.org Wed Jan 31 17:53:03 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 31 Jan 2024 17:53:03 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 16:44:17 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Swith to using Unsafe src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 82: > 80: private static final class Deallocator implements Runnable { > 81: > 82: private static final long INVOKED_OFFSET = Unsafe.getUnsafe() There are two invocations of Unsafe.getUnsafe introduced here, while the base class Buffer has initialised the static UNSAFE (i.e. the reference used for freeMemory.) Could this static be used to replace Unsafe.getUnsafe ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1473227017 From msheppar at openjdk.org Wed Jan 31 18:01:03 2024 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 31 Jan 2024 18:01:03 GMT Subject: RFR: 8324972: (bf) Make DirectByteBuffer.Deallocator idempotent [v3] In-Reply-To: References: Message-ID: On Wed, 31 Jan 2024 16:44:17 GMT, Per Minborg wrote: >> This PR proposes to make deallocators and unmappers for memory regions idempotent. This is to prevent (likely very rare) duplicate invocations. >> >> There are no unit tests but it should be noted that the idempotent behavior (now correct) is similar to the intended behavior before cf74b8c2a32f33019a13ce80b6667da502cc6722 but where idempotency was not guaranteed in a multi-threaded environment. >> >> Passes tier1, 2, and 3 tests. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Swith to using Unsafe src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 99: > 97: public void run() { > 98: // Ensure idempotency (paranoia) > 99: if (Unsafe.getUnsafe().compareAndSetInt(this, INVOKED_OFFSET, 0, 1)) { a question for my edification: is this compound statement suitably atomic to ensure synchronzied serial access to freeMemory block ? There's no danger of concurrent interleaved execution resulting in inconsistent view of the member variable via the reflective access ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17647#discussion_r1473240178