From alanb at openjdk.org Fri Jul 1 12:58:33 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Jul 2022 12:58:33 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v4] In-Reply-To: References: Message-ID: <23jI1ok1qwORE_X4PtTd2FVrysXejptCVmW61ZaCDDQ=.69b7a066-136e-43b0-9b43-1c5230608424@github.com> On Mon, 27 Jun 2022 16:43:55 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updated tests based on feedback test/jdk/java/nio/file/spi/TestDelegation.java line 111: > 109: assertEquals(1, PROVIDER.findCall("exists").size()); > 110: assertEquals(2, PROVIDER.findCall("readAttributesIfExists").size()); > 111: PROVIDER.resetCalls(); One suggestion is to split these into testExists, testIsDirectory and testIsRegularFile so that the delegation of each method is tested in isolation. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From bpb at openjdk.org Fri Jul 1 15:22:54 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 1 Jul 2022 15:22:54 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v11] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). 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 14 additional commits since the last revision: - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() - Merge - 8057113: Change @since annotation to 20 - Merge - 8057113: Remove superfluous new Object[] statements from test - 8057113: Fix getExtension() commcents; improve hasExtension() implementation - 8057113: trailing dot yields empty string extension; add test - Merge - 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes - 8057113: Clean up trailing whitespace - ... and 4 more: https://git.openjdk.org/jdk/compare/e1633ae0...d11ef42a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/4b5166ba..d11ef42a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=09-10 Stats: 39579 lines in 1023 files changed: 15300 ins; 12347 del; 11932 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From rriggs at openjdk.org Fri Jul 1 15:38:50 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 1 Jul 2022 15:38:50 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v11] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 15:22:54 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > 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 14 additional commits since the last revision: > > - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() > - Merge > - 8057113: Change @since annotation to 20 > - Merge > - 8057113: Remove superfluous new Object[] statements from test > - 8057113: Fix getExtension() commcents; improve hasExtension() implementation > - 8057113: trailing dot yields empty string extension; add test > - Merge > - 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes > - 8057113: Clean up trailing whitespace > - ... and 4 more: https://git.openjdk.org/jdk/compare/c0042581...d11ef42a src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 39: > 37: import java.net.URI; > 38: import java.util.Objects; > 39: These can be reverted; no changes needed in UnixPath. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Fri Jul 1 16:04:04 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 1 Jul 2022 16:04:04 GMT Subject: RFR: 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB Message-ID: The test fails when an expected size is greater than 1 GiB but there is no indication of how much the size deviates from the expected value. This information might be helpful in adjusting the threshold. ------------- Commit messages: - 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB Changes: https://git.openjdk.org/jdk/pull/9347/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9347&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289584 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9347.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9347/head:pull/9347 PR: https://git.openjdk.org/jdk/pull/9347 From alanb at openjdk.org Fri Jul 1 16:10:32 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 1 Jul 2022 16:10:32 GMT Subject: RFR: 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB In-Reply-To: References: Message-ID: <_8nY9_Da0KBSE-enwkTD9BDqYtP-_5MGL0FcFi3IraE=.ae65c14e-97ab-42ff-a89d-645ef10269e4@github.com> On Fri, 1 Jul 2022 15:57:57 GMT, Brian Burkhalter wrote: > The test fails when an expected size is greater than 1 GiB but there is no indication of how much the size deviates from the expected value. This information might be helpful in adjusting the threshold. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9347 From bpb at openjdk.org Fri Jul 1 19:17:45 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 1 Jul 2022 19:17:45 GMT Subject: Integrated: 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB In-Reply-To: References: Message-ID: <8jK3tsOQxnSAm0bumtR79bDnS4h0CCRNbTdeWwn3noQ=.a6ba33e0-08f4-4116-9f76-40f67c52927b@github.com> On Fri, 1 Jul 2022 15:57:57 GMT, Brian Burkhalter wrote: > The test fails when an expected size is greater than 1 GiB but there is no indication of how much the size deviates from the expected value. This information might be helpful in adjusting the threshold. This pull request has now been integrated. Changeset: e291a67e Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/e291a67e96970d80a9915f8a23afffed6e0b8ded Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod 8289584: (fs) Print size values in java/nio/file/FileStore/Basic.java when they differ by > 1GiB Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9347 From attila at openjdk.org Sun Jul 3 20:22:27 2022 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 3 Jul 2022 20:22:27 GMT Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov wrote: >> There is overload method HashMap.remove(key,value) which also checks value equality. >> It's shorter and faster than pair get+remove. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem > update copyright year Marked as reviewed by attila (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9314 From aturbanov at openjdk.org Mon Jul 4 06:57:00 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 06:57:00 GMT Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem [v2] In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov wrote: >> There is overload method HashMap.remove(key,value) which also checks value equality. >> It's shorter and faster than pair get+remove. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem > update copyright year Thank you for review! ------------- PR: https://git.openjdk.org/jdk/pull/9314 From aturbanov at openjdk.org Mon Jul 4 06:57:01 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 4 Jul 2022 06:57:01 GMT Subject: Integrated: 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem In-Reply-To: References: Message-ID: <0LymFuLrSfkaiN7IOjWqiVLFrO-9mt1ZQJyjBIsBQT0=.d422573a-58be-40f0-93e5-ec0c9dc8c751@github.com> On Tue, 28 Jun 2022 21:07:41 GMT, Andrey Turbanov wrote: > There is overload method HashMap.remove(key,value) which also checks value equality. > It's shorter and faster than pair get+remove. This pull request has now been integrated. Changeset: 8e7a3cb5 Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/8e7a3cb5ab3852f0c367c8807d51ffbec2d0ad49 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem Reviewed-by: lancea, attila ------------- PR: https://git.openjdk.org/jdk/pull/9314 From alanb at openjdk.org Mon Jul 4 17:34:38 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 17:34:38 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: <64SjVJVDINXcksAWLw4EuvYbTt7YHTBW1oheL3v1Ieg=.28e30958-b4f1-4ead-a180-20475d69504c@github.com> On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele wrote: > This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java. > > I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon. > > ### Testing > I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`: > > - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation. > - DeleteInterference.java fails for the same reason as above. > - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so. I don't know AIX or the /aha file system so the following are just a few general comments to help with this feature. I added AbstractPoller a long time ago as the base class for implementation so my reading of this patch is that it works here too. If I understand correctly then watching a directory involves create a mirror in /aha. I see the patch uses Files.createDirectories for that. I suspect you really want toRealPath rather than normalise + toAbsolutePath. Calling Files means you are calling the API from the provider which will be problematic if the default provider is configured to be something else. Also I'm quite sure this won't work with a security manager as the code is missing a doPrivileged. A general point about the NIO area is that we've always tried to keep the native methods as simple as possible, preferably just call one syscall. The loops in the native methods in the native methods in this patch can all be hoisted to the Java code which will make it much easier to maintain. A general point of code style is to just to keep it as simple as possible. There are some strange formatting in many areas. Also lines of line 170+ characters are a pain for future side-by-side diffs so keeping lines to sane line would be helpful. ------------- PR: https://git.openjdk.org/jdk/pull/9281 From lancea at openjdk.org Mon Jul 4 19:15:37 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 4 Jul 2022 19:15:37 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v5] In-Reply-To: References: Message-ID: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Separated test cases out and added benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/63b97ce3..a51010aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=03-04 Stats: 212 lines in 2 files changed: 198 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Mon Jul 4 19:30:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 4 Jul 2022 19:30:40 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: Message-ID: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Address whitespace issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/a51010aa..240c38b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From alanb at openjdk.org Mon Jul 4 19:32:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Jul 2022 19:32:58 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> Message-ID: <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> On Mon, 4 Jul 2022 19:30:40 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Address whitespace issue The updated TestDelegation test is looking a bit better now but I think it would be simplified a lot more by getting rid of the data providers, just aren't needed in this test. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Tue Jul 5 09:57:47 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 09:57:47 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Mon, 4 Jul 2022 19:30:50 GMT, Alan Bateman wrote: > The updated TestDelegation test is looking a bit better now but I think it would be simplified a lot more by getting rid of the data providers, just aren't needed in this test. Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From alanb at openjdk.org Tue Jul 5 11:00:43 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Jul 2022 11:00:43 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Tue, 5 Jul 2022 09:54:15 GMT, Lance Andersen wrote: > Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. Okay, but there are a few other things to mention: One issue is the reset method is called at the end of each test. I think it needs to be at the beginning of the method, moved to a finally block of a try-finally, or maybe @BeforeMethod to reset before each test. The reason is that one test failing will cause the tests that follow to fail too. The fields aren't constants so looks a bit strange (to me anyway) to be in uppercase. If you rename them then I think the tests would be a bit more readable. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From bpb at openjdk.org Tue Jul 5 16:06:24 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Jul 2022 16:06:24 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v12] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Revert excision of wild cards from imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/d11ef42a..ec0a341e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=10-11 Stats: 11 lines in 1 file changed: 0 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Tue Jul 5 16:06:31 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Jul 2022 16:06:31 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v11] In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 15:35:25 GMT, Roger Riggs wrote: >> 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 14 additional commits since the last revision: >> >> - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() >> - Merge >> - 8057113: Change @since annotation to 20 >> - Merge >> - 8057113: Remove superfluous new Object[] statements from test >> - 8057113: Fix getExtension() commcents; improve hasExtension() implementation >> - 8057113: trailing dot yields empty string extension; add test >> - Merge >> - 8057113: String getExtension(String defaultExtension) to Optional getExtension() and other changes >> - 8057113: Clean up trailing whitespace >> - ... and 4 more: https://git.openjdk.org/jdk/compare/3308a95b...d11ef42a > > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 39: > >> 37: import java.net.URI; >> 38: import java.util.Objects; >> 39: > > These can be reverted; no changes needed in UnixPath. Reverted in ec0a341ef8186482c73c1909ffeaf061c26afc36. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Tue Jul 5 16:53:15 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Jul 2022 16:53:15 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v13] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Remove extensions() test method; add threthree new test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/ec0a341e..ec417a89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=11-12 Stats: 18 lines in 1 file changed: 3 ins; 15 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Tue Jul 5 16:53:16 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 5 Jul 2022 16:53:16 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v9] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 10:38:30 GMT, Lance Andersen wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8057113: Remove superfluous new Object[] statements from test > > test/jdk/java/nio/file/Path/Extensions.java line 38: > >> 36: * @run testng Extensions >> 37: */ >> 38: public class Extensions { > > Can you add a test to exercise the change you made to ZipFS->ZipPath That code has been reverted. > test/jdk/java/nio/file/Path/Extensions.java line 95: > >> 93: {"video.mp4", of("mp4")}, >> 94: {"document.txt", of("txt")}, >> 95: }; > > Should we add a x.zip, y.gzip, and z.jar given they are common? Done in ec417a8938a6e50a473c2f3c9242f9a897f189b6. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From alanb at openjdk.org Tue Jul 5 19:20:25 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v7] In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 19:17:27 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the following patch which will: >> >> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods >> >> - public boolean exists(Path path, LinkOption... options) >> - public A readAttributesIfExists(Path path, Class type, LinkOption... options) >> >> >> This change allows for providers to provide optimizations when the file's attributes are not needed. >> >> Mach5 tiers 1 - 3 run clean with this change >> >> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) >> >> >> Best, >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add @BeforeMethod and rename fields I think all my comments have been addressed so I think this is good to go. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Tue Jul 5 19:48:02 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:48:02 GMT Subject: Integrated: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen wrote: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance This pull request has now been integrated. Changeset: d48694d0 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/d48694d0f3865c1b205acdfa2e6c6d032a39959d Stats: 712 lines in 13 files changed: 537 ins; 135 del; 40 mod 8283335: Add exists and readAttributesIfExists methods to FileSystemProvider Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Tue Jul 5 19:20:25 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v6] In-Reply-To: References: <7-12kMA18Lf4PWFBikXvp-Ws1yWLoAcd1fuiSPnQPCg=.086acd40-e34f-4cf1-a962-dd67a9e84d7b@github.com> <5MrbI92DrJYo4lim8B3EnWc8a2zck0Jn5re60tE8aig=.3c86d866-97d9-4335-891e-4f124df9ee74@github.com> Message-ID: On Tue, 5 Jul 2022 10:56:45 GMT, Alan Bateman wrote: > > Unless you feel this is a must, I would prefer to keep the DataProviders. The benefit I see is the test code does not need to be duplicated per parameter, each test scenario can be run as an individual test so that you do not need extra plumbing to run each test scenario in the unlikely event of a failure. > > Okay, but there are a few other things to mention: > > One issue is the reset method is called at the end of each test. I think it needs to be at the beginning of the method, moved to a finally block of a try-finally, or maybe @BeforeMethod to reset before each test. The reason is that one test failing will cause the tests that follow to fail too. Good catch, added `@BeforeMethod` > > The fields aren't constants so looks a bit strange (to me anyway) to be in uppercase. If you rename them then I think the tests would be a bit more readable. Ah, sometimes you see what you want. I must have had fields on my mind when I did that as I completely agree with you. Both of the above are addressed in the latest update to the PR. Thank you for the feedback. ------------- PR: https://git.openjdk.org/jdk/pull/9249 From lancea at openjdk.org Tue Jul 5 19:20:25 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 5 Jul 2022 19:20:25 GMT Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to FileSystemProvider [v7] In-Reply-To: References: Message-ID: > Hi, > > Please review the following patch which will: > > - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods > > - public boolean exists(Path path, LinkOption... options) > - public A readAttributesIfExists(Path path, Class type, LinkOption... options) > > > This change allows for providers to provide optimizations when the file's attributes are not needed. > > Mach5 tiers 1 - 3 run clean with this change > > The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336) > > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add @BeforeMethod and rename fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9249/files - new: https://git.openjdk.org/jdk/pull/9249/files/240c38b8..74436951 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=05-06 Stats: 36 lines in 1 file changed: 9 ins; 3 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/9249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249 PR: https://git.openjdk.org/jdk/pull/9249 From djelinski at openjdk.org Tue Jul 5 21:06:58 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 5 Jul 2022 21:06:58 GMT Subject: RFR: 8289768: Clean up unused code Message-ID: This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. ------------- Commit messages: - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) Changes: https://git.openjdk.org/jdk/pull/9383/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289768 Stats: 69 lines in 45 files changed: 0 ins; 65 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Wed Jul 6 08:57:23 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 08:57:23 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Wed Jul 6 05:32:29 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Jul 2022 05:32:29 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables - Remove unused variables (windows) - Remove unused variables (macos) - Remove unused variables (linux) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00-01 Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From dfuchs at openjdk.org Wed Jul 6 09:39:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 6 Jul 2022 09:39:28 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate, ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From jvernee at openjdk.org Wed Jul 6 17:00:47 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:00:47 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: <9ZEADSzSlDzVxEDuF3KT1bgynXFLLtLmXZi1XszM0D0=.ff3a84ef-d38b-4daa-920e-acee3ee97e6c@github.com> On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert implicit vs. heap session changes Am I understanding correctly that, before calling `checkValidState` we also need to always call `baseSession()`? `checkValidState()` just calls `checkValidStateRaw` in a try/catch, and for non-closeable views this always throws. There seem to be many cases where `baseSession()` is not called... ------------- PR: https://git.openjdk.org/jdk19/pull/22 From mcimadamore at openjdk.org Wed Jul 6 18:01:28 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 18:01:28 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v5] In-Reply-To: References: Message-ID: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into memory_session_cleanup - Fix ambiguity between session vs. base session - Revert implicit vs. heap session changes - Unify heap vs. implicit scopes - Merge branch 'master' into memory_session_cleanup - Fix issue in Direct-X-Buffer template - Simplify and drop the state class - Add missing files - Initial push ------------- Changes: https://git.openjdk.org/jdk19/pull/22/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04 Stats: 484 lines in 24 files changed: 56 ins; 107 del; 321 mod Patch: https://git.openjdk.org/jdk19/pull/22.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22 PR: https://git.openjdk.org/jdk19/pull/22 From jvernee at openjdk.org Wed Jul 6 17:11:55 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:11:55 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: <37B_wovfu8uoaM0hq4X1PG3xccVavpwYiZcJ9uNpqTM=.e417015c-9cef-4125-88cb-346b0a80471e@github.com> On Wed, 6 Jul 2022 17:05:51 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert implicit vs. heap session changes > > src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131: > >> 129: AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true); >> 130: #if[floatingPoint] >> 131: $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(), > > For instance, it's not clear to me why `baseSession()` is not called here. It seems that, if `get$RawType$Unaligned` calls `checkValidStateRaw()` this will end up throwing an exception ------------- PR: https://git.openjdk.org/jdk19/pull/22 From jvernee at openjdk.org Wed Jul 6 17:11:54 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 6 Jul 2022 17:11:54 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert implicit vs. heap session changes src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131: > 129: AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true); > 130: #if[floatingPoint] > 131: $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(), For instance, it's not clear to me why `baseSession()` is not called here. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172: > 170: > 171: public Builder(MemorySession session) { > 172: ((MemorySessionImpl)session).checkValidState(); Or here, if the memory session is a non-closeable view. ------------- PR: https://git.openjdk.org/jdk19/pull/22 From mcimadamore at openjdk.org Wed Jul 6 17:16:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 17:16:56 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v4] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 17:07:37 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert implicit vs. heap session changes > > src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172: > >> 170: >> 171: public Builder(MemorySession session) { >> 172: ((MemorySessionImpl)session).checkValidState(); > > Or here, if the memory session is a non-closeable view. I believe there was a wrong renaming with the IDE here, I will fix this ------------- PR: https://git.openjdk.org/jdk19/pull/22 From weijun at openjdk.org Wed Jul 6 16:44:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 6 Jul 2022 16:44:53 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From lancea at openjdk.org Wed Jul 6 15:35:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 6 Jul 2022 15:35:39 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) zlib looks fine given it is openjdk and not an upstream needed change ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From smarks at openjdk.org Thu Jul 7 00:34:45 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 7 Jul 2022 00:34:45 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. @liach > 'the new' fix should be applied to newHashMap etc. too. I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From naoto at openjdk.org Wed Jul 6 19:46:33 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 6 Jul 2022 19:46:33 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From mcimadamore at openjdk.org Wed Jul 6 21:50:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 21:50:39 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v5] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 18:01:28 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Merge branch 'master' into memory_session_cleanup > - Fix ambiguity between session vs. base session > - Revert implicit vs. heap session changes > - Unify heap vs. implicit scopes > - Merge branch 'master' into memory_session_cleanup > - Fix issue in Direct-X-Buffer template > - Simplify and drop the state class > - Add missing files > - Initial push I've fixed the issues in the review comments, and further reduced the differences between the contents of this patch and mainline (while retaining the improvements). ------------- PR: https://git.openjdk.org/jdk19/pull/22 From mcimadamore at openjdk.org Wed Jul 6 21:50:36 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 6 Jul 2022 21:50:36 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v6] In-Reply-To: References: Message-ID: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Turn non-closeable view back into MemorySession impl ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/22/files - new: https://git.openjdk.org/jdk19/pull/22/files/09bb7cf3..809a0a2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04-05 Stats: 79 lines in 14 files changed: 7 ins; 11 del; 61 mod Patch: https://git.openjdk.org/jdk19/pull/22.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22 PR: https://git.openjdk.org/jdk19/pull/22 From cjplummer at openjdk.org Thu Jul 7 19:16:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Jul 2022 19:16:48 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: References: Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables > - Remove unused variables (windows) > - Remove unused variables (macos) > - Remove unused variables (linux) Are you going to update copyrights? I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c. src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > 306: ELF_SHDR* shbuf = NULL; > 307: ELF_SHDR* cursct = NULL; > 308: ELF_PHDR* phbuf = NULL; phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From tsteele at openjdk.org Thu Jul 7 16:50:39 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 7 Jul 2022 16:50:39 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele wrote: > This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java. > > I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon. > > ### Testing > I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`: > > - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation. > - DeleteInterference.java fails for the same reason as above. > - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so. Thanks for your comments Alan: > I suspect you really want toRealPath rather than normalise + toAbsolutePath. Thanks for pointing that out. Yes, that method is what I was looking for. I have made this change. > Calling Files means you are calling the API from the provider which will be problematic if the default provider is configured to be something else. I debated creating and using an instance of AixFileSystem directly. It didn't seem like it would be worth the trouble, but I'm open to changing that opinion. If this code is somehow being run on a non-AIX machine, I'm sure this would not be their only issue. There is another complication if we go this route: createDirectories is implemented in Files.java, so using createDirectory from AixFileSystem would mean duplicating this functionality in my implementation. > Also I'm quite sure this won't work with a security manager as the code is missing a doPrivileged. I'm sure you're right. I didn't think too hard about the Security Manager since it is now depreciated. I agree that there are a few places that would cause issues. If preferred, I am happy to work in any changes necessary to support it. > The loops ... in the native methods in this patch can all be hoisted to the Java code which will make it much easier to maintain. This is tricky, since the loops examine values in the c-struct. Without a StructLayout object or some other way of examining values in foreign memory, I'm not sure how to do this in a clean way. Maybe there is a solution for manipulating c-structs in Java that I am not aware of; the way to do this that I am familiar with is currently a preview API (JEP-424). > Also lines of line 170+ characters are a pain for future side-by-side diffs so keeping lines to sane line would be helpful. I've wrapped the longer lines. I am also happy to change any formatting, just let me know what you'd like changed. ------------- PR: https://git.openjdk.org/jdk/pull/9281 From dcubed at openjdk.org Thu Jul 7 22:07:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 7 Jul 2022 22:07:45 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Thumbs up. I didn't realize that other test dirs already had the mechanism in place to isolate the resource hogs. I'm looking forward to seeing this in action. I just realized this is targeted at jdk/jdk (JDK20). Can you please close this PR and create a new one for JDK19? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:29:37 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:37 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> References: <0gPmAVZXUW0z72hLHK55ww6D6WMw_g7EZrhpCmgQZqo=.ae89ee63-1884-400b-9cbc-9b264749ab2f@github.com> Message-ID: <7mygwAjMURF-MohcFrd-sViGCDTgy01k6uxAWPt8uQM=.ff301290-c7d6-47cd-b95b-33d1304900c1@github.com> On Thu, 7 Jul 2022 22:04:09 GMT, Daniel D. Daugherty wrote: > I just realized this is targeted at jdk/jdk (JDK20). Can you please close this PR and create a new one for JDK19? Done. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:39:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Message-ID: Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Redirected from https://github.com/openjdk/jdk/pull/9416. ------------- Commit messages: - 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Changes: https://git.openjdk.org/jdk19/pull/122/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278469 Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/122.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/122/head:pull/122 PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Thu Jul 7 22:29:38 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:38 GMT Subject: Withdrawn: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:39:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. It is conjectured that several tests with large memory demands such as these could be failing due to insufficient memory per core on the test node when the tests are run simultaneously. ------------- PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Thu Jul 7 22:29:35 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:29:35 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Superseded by https://github.com/openjdk/jdk19/pull/122 ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 20:46:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 20:46:06 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Message-ID: Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. ------------- Commit messages: - 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out Changes: https://git.openjdk.org/jdk/pull/9416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8278469 Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9416.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9416/head:pull/9416 PR: https://git.openjdk.org/jdk/pull/9416 From dcubed at openjdk.org Thu Jul 7 22:39:12 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 7 Jul 2022 22:39:12 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Thu Jul 7 20:46:07 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 20:46:07 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. It is conjectured that several tests with large memory demands such as these could be failing due to insufficient memory per core on the test node when the tests are run simultaneously. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Thu Jul 7 22:39:13 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 7 Jul 2022 22:39:13 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. This pull request has now been integrated. Changeset: 11319c2a Author: Brian Burkhalter URL: https://git.openjdk.org/jdk19/commit/11319c2aeb16ef2feb0ecab0e2811a52e845739d Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out 8289526: java/nio/channels/FileChannel/MapTest.java times out Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk19/pull/122 From djelinski at openjdk.org Fri Jul 8 07:08:46 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: - Update copyright - Remove more unused variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9383/files - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01-02 Stats: 30 lines in 26 files changed: 0 ins; 4 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9383.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383 PR: https://git.openjdk.org/jdk/pull/9383 From cjplummer at openjdk.org Fri Jul 8 07:20:46 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 8 Jul 2022 07:20:46 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 06:35:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 06:35:40 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> On Thu, 7 Jul 2022 20:36:43 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. Are you sure MapTest needs a lot of memory? It's a unit test and doesn't have anything in its jtreg test description to require a lot of resources. I wonder if it's just the victim. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From duke at openjdk.org Fri Jul 8 13:55:47 2022 From: duke at openjdk.org (XenoAmess) Date: Fri, 8 Jul 2022 13:55:47 GMT Subject: RFR: 8284780: Need methods to create pre-sized HashSet and LinkedHashSet [v17] In-Reply-To: References: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com> Message-ID: On Wed, 1 Jun 2022 16:45:35 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> do it as naotoj said > > 'the new' fix should be applied to newHashMap etc. too. > @liach > > > 'the new' fix should be applied to newHashMap etc. too. > > I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it. Sorry for I already forgotten it. ------------- PR: https://git.openjdk.org/jdk/pull/8302 From bpb at openjdk.org Fri Jul 8 15:20:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 15:20:44 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: <3cfOXUr2YS6mzQkZLwJhMOb5HStzTbSRxwnch04R8kA=.a8439f5f-c986-4696-9436-bb4cf9edba86@github.com> On Fri, 8 Jul 2022 11:12:26 GMT, Jaikiran Pai wrote: > Hello Brian, should `java/nio/channels/Channels/ReadXBytes.java` be treated similarly to prevent https://bugs.openjdk.org/browse/JDK-8289470? That test uses `-Xmx12G`, so probably would need to be running exclusively? Probably. I had been considering because of this [prior comment](https://github.com/openjdk/jdk19/pull/122#issuecomment-1178864972). ------------- PR: https://git.openjdk.org/jdk19/pull/122 From jvernee at openjdk.org Fri Jul 8 11:25:56 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 8 Jul 2022 11:25:56 GMT Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session [v6] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 21:50:36 GMT, Maurizio Cimadamore wrote: >> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Turn non-closeable view back into MemorySession impl Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/22 From jpai at openjdk.org Fri Jul 8 11:15:41 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 8 Jul 2022 11:15:41 GMT Subject: [jdk19] Integrated: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 22:25:10 GMT, Brian Burkhalter wrote: > Modify test directives so that `LargeGatheringWrite` and `MapTest` in `java/nio/channels/FileChannel` are not run concurrently with other tests. > > Redirected from https://github.com/openjdk/jdk/pull/9416. Hello Brian, should `java/nio/channels/Channels/ReadXBytes.java` be treated similarly to prevent https://bugs.openjdk.org/browse/JDK-8289470? That test uses `-Xmx12G`, so probably would need to be running exclusively? ------------- PR: https://git.openjdk.org/jdk19/pull/122 From bpb at openjdk.org Fri Jul 8 15:18:53 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 15:18:53 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 06:30:53 GMT, Alan Bateman wrote: > Are you sure MapTest needs a lot of memory? It's a unit test and doesn't have anything in its jtreg test description to require a lot of resources. I wonder if it's just the victim. We can see whether they both stop failing regularly after this change and if so move `MapTest` out of the large memory list. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From alanb at openjdk.org Fri Jul 8 07:57:43 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 07:57:43 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: On Thu, 7 Jul 2022 16:47:22 GMT, Tyler Steele wrote: > > Calling Files means you are calling the API from the provider which will be problematic if the default provider is configured to be something else. > > I debated creating and using an instance of AixFileSystem directly. It didn't seem like it would be worth the trouble, but I'm open to changing that opinion. If this code is somehow being run on a non-AIX machine, I'm sure this would not be their only issue. There is another complication if we go this route: createDirectories is implemented in Files.java, so using createDirectory from AixFileSystem would mean duplicating this functionality in my implementation. It is "architectural broken" to call back into the API from the implementation. It may not be visible now but it will surface once you run in environments where the default file system provider is replaced. > I'm sure you're right. I didn't think too hard about the Security Manager since it is now depreciated. I agree that there are a few places that would cause issues. If preferred, I am happy to work in any changes necessary to support it. SecurityManager may be terminally deprecated but it's still a supported execution mode so the new code will need to work with a SM. > This is tricky, since the loops examine values in the c-struct. Without a StructLayout object or some other way of examining values in foreign memory, I'm not sure how to do this in a clean way. Maybe there is a solution for manipulating c-structs in Java that I am not aware of; the way to do this that I am familiar with is currently a preview API (JEP-424). There are many examples in the NIO implementation that access the fields in structs from Java code. In the Linux implementation of WatchService you'll see it access the inotify_event structure directly. In time I expect new code will make more use of the new Panama APIs and maybe some of the existing code will be migrated. ------------- PR: https://git.openjdk.org/jdk/pull/9281 From alanb at openjdk.org Fri Jul 8 08:03:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 08:03:39 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Marked as reviewed by alanb (Reviewer). src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686: > 684: LPCWSTR lpFileName = jlong_to_ptr(pathAddress); > 685: PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress); > 686: DWORD lengthNeeded = 0; lengthNeeded, it seems not :-) ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:12:44 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:12:44 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables Copyrights updated. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From djelinski at openjdk.org Fri Jul 8 07:08:50 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 8 Jul 2022 07:08:50 GMT Subject: RFR: 8289768: Clean up unused code [v2] In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> References: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com> Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com> On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer wrote: >> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables >> - Remove unused variables (windows) >> - Remove unused variables (macos) >> - Remove unused variables (linux) > > src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308: > >> 306: ELF_SHDR* shbuf = NULL; >> 307: ELF_SHDR* cursct = NULL; >> 308: ELF_PHDR* phbuf = NULL; > > phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too. Good catch! Also removed similar code from macOS version. ------------- PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Fri Jul 8 16:58:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 16:58:29 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 15:15:03 GMT, Brian Burkhalter wrote: > We can see whether they both stop failing regularly after this change and if so move `MapTest` out of the large memory list. I suspect it's a victim and shouldn't in the largeMemory directory but let's see if there are issues in the coming days. My preference is to keep the unit tests in the original location and the only tests in largeMemory are the tests that really need a lot of memory. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From bpb at openjdk.org Fri Jul 8 18:17:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 8 Jul 2022 18:17:44 GMT Subject: RFR: 8278469: Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out In-Reply-To: References: <9LqC6U6InHFitck7W6uB3WLAilpIF3DerFRKSqrEhpg=.3f3f930b-9090-4eed-8a15-bf40eb50b385@github.com> Message-ID: On Fri, 8 Jul 2022 16:55:28 GMT, Alan Bateman wrote: > My preference is to keep the unit tests in the original location and the only tests in largeMemory are the tests that really need a lot of memory. Likewise. ------------- PR: https://git.openjdk.org/jdk/pull/9416 From lancea at openjdk.org Fri Jul 8 18:28:07 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:28:07 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException Message-ID: Hi all, Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go Best Lance ------------- Commit messages: - Fix for JDK-8289984 Changes: https://git.openjdk.org/jdk/pull/9433/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289984 Stats: 10 lines in 2 files changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9433.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9433/head:pull/9433 PR: https://git.openjdk.org/jdk/pull/9433 From lancea at openjdk.org Fri Jul 8 18:39:38 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:39:38 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:13:56 GMT, Lance Andersen wrote: > Hi all, > > Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled > > The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go > > Best > Lance The previously failing jck tests are now passing on mach5 ------------- PR: https://git.openjdk.org/jdk/pull/9433 From iris at openjdk.org Fri Jul 8 18:44:47 2022 From: iris at openjdk.org (Iris Clark) Date: Fri, 8 Jul 2022 18:44:47 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:13:56 GMT, Lance Andersen wrote: > Hi all, > > Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled > > The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go > > Best > Lance Marked as reviewed by iris (Reviewer). test/jdk/java/nio/file/Files/CheckPermissions.java line 219: > 217: > 218: prepare(); > 219: exists(file); Sorry for the poor comment placement. Do you need to add the bugid back at line 25? ------------- PR: https://git.openjdk.org/jdk/pull/9433 From alanb at openjdk.org Fri Jul 8 18:48:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Jul 2022 18:48:50 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:13:56 GMT, Lance Andersen wrote: > Hi all, > > Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled > > The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go > > Best > Lance Can you update the @bug tag before you integrate? ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/9433 From lancea at openjdk.org Fri Jul 8 18:59:32 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:59:32 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException [v2] In-Reply-To: References: Message-ID: <53QtKEwcE7XAiu4izz7rVY0BHYXEhHgn_vEMT0aIEi0=.dac88599-1889-4d83-afab-6f9585634f70@github.com> > Hi all, > > Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled > > The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: added bug number to @bug in CheckPermissions.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9433/files - new: https://git.openjdk.org/jdk/pull/9433/files/b2d2cf75..52d758e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9433&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9433&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9433.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9433/head:pull/9433 PR: https://git.openjdk.org/jdk/pull/9433 From lancea at openjdk.org Fri Jul 8 18:59:32 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:59:32 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:46:08 GMT, Alan Bateman wrote: > Can you update the @bug tag before you integrate? Done and pushed. Thanks for the reminder ------------- PR: https://git.openjdk.org/jdk/pull/9433 From lancea at openjdk.org Fri Jul 8 18:59:33 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:59:33 GMT Subject: RFR: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException [v2] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:40:30 GMT, Iris Clark wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> added bug number to @bug in CheckPermissions.java > > test/jdk/java/nio/file/Files/CheckPermissions.java line 219: > >> 217: >> 218: prepare(); >> 219: exists(file); > > Sorry for the poor comment placement. Do you need to add the bugid back at line 25? Thanks for the reminder and all set. ------------- PR: https://git.openjdk.org/jdk/pull/9433 From lancea at openjdk.org Fri Jul 8 18:59:34 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 8 Jul 2022 18:59:34 GMT Subject: Integrated: 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 18:13:56 GMT, Lance Andersen wrote: > Hi all, > > Please review this change to address the fact that we were missing a permissions check when the SecurityManager is enabled > > The failing jck tests are passing locally and just waiting on another platform to complete on Mach5 and will be good to go > > Best > Lance This pull request has now been integrated. Changeset: 6aaf141f Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/6aaf141f61416104020107c371592812a4c723d9 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod 8289984: Files:isDirectory and isRegularFile methods not throwing SecurityException Reviewed-by: iris, alanb ------------- PR: https://git.openjdk.org/jdk/pull/9433 From duke at openjdk.org Fri Jul 8 19:43:49 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 8 Jul 2022 19:43:49 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.org/jdk/pull/4263 From duke at openjdk.org Sun Jul 10 09:53:46 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 10 Jul 2022 09:53:46 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16] In-Reply-To: References: Message-ID: On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel. > > Markus KARG has updated the pull request incrementally with three additional commits since the last revision: > > - separate test class for each large file test > - Base class only contains utilities and helpers > - Renamed AbstractTransferTo to TransferToBase as it is not abstract Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From michaelm at openjdk.org Mon Jul 11 07:00:45 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 11 Jul 2022 07:00:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables libnet changes look fine to me ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From alanb at openjdk.org Mon Jul 11 07:09:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 11 Jul 2022 07:09:04 GMT Subject: RFR: 8290002: (se) AssertionError in SelectorImpl.implCloseSelector Message-ID: This change adjusts an incorrect assert in the Selector implementation. The assert is incorrect since JDK 11 and JDK-8201315. The correct assert here is to test that the selector's selected-key set is empty. The selector's key set is not guaranteed to be empty here as there may be other threads registering channels while the selector is being closed. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/9442/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9442&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290002 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9442.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9442/head:pull/9442 PR: https://git.openjdk.org/jdk/pull/9442 From chegar at openjdk.org Mon Jul 11 08:13:45 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Mon, 11 Jul 2022 08:13:45 GMT Subject: RFR: 8289768: Clean up unused code [v3] In-Reply-To: References: Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com> On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski wrote: >> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. >> >> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. >> >> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. > > Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright > - Remove more unused variables LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/9383 From michaelm at openjdk.org Mon Jul 11 11:21:50 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 11 Jul 2022 11:21:50 GMT Subject: RFR: 8290002: (se) AssertionError in SelectorImpl.implCloseSelector In-Reply-To: References: Message-ID: On Sun, 10 Jul 2022 06:54:56 GMT, Alan Bateman wrote: > This change adjusts an incorrect assert in the Selector implementation. The assert is incorrect since JDK 11 and JDK-8201315. The correct assert here is to test that the selector's selected-key set is empty. The selector's key set is not guaranteed to be empty here as there may be other threads registering channels while the selector is being closed. LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR: https://git.openjdk.org/jdk/pull/9442 From jwilhelm at openjdk.org Mon Jul 11 12:46:47 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 11 Jul 2022 12:46:47 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8290004: [PPC64] JfrGetCallTrace: assert(_pc != nullptr) failed: must have PC - 8289692: JFR: Thread checkpoint no longer enforce mutual exclusion post Loom integration - 8289894: A NullPointerException thrown from guard expression - 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap - 8282071: Update java.xml module-info - 8290033: ProblemList serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java on windows-x64 in -Xcomp mode - 8289697: buffer overflow in MTLVertexCache.m: MTLVertexCache_AddGlyphQuad - 8289872: wrong wording in @param doc for HashMap.newHashMap et. al. - 8289601: SegmentAllocator::allocateUtf8String(String str) should be clarified for strings containing \0 - ... and 5 more: https://git.openjdk.org/jdk/compare/46251bc6...0b0d186f The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9450&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9450/files Stats: 411 lines in 43 files changed: 284 ins; 26 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/9450.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9450/head:pull/9450 PR: https://git.openjdk.org/jdk/pull/9450 From mcimadamore at openjdk.org Mon Jul 11 14:33:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 14:33:12 GMT Subject: [jdk19] Integrated: 8287809: Revisit implementation of memory session In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore wrote: > This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017 This pull request has now been integrated. Changeset: fed3af8a Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk19/commit/fed3af8ae069fc760a24e750292acbb468b14ce5 Stats: 429 lines in 21 files changed: 47 ins; 102 del; 280 mod 8287809: Revisit implementation of memory session Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk19/pull/22 From mcimadamore at openjdk.org Mon Jul 11 14:41:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 14:41:40 GMT Subject: [jdk19] RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup [v2] In-Reply-To: References: Message-ID: > This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases: > > * when a buffer segment is created, to keep the original buffer instance reachable > * when a loader symbol lookup is created, to keep the classloader instance reachable > > Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model. > > This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments. > > This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case. Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Initial push - Revert implicit vs. heap session changes - Unify heap vs. implicit scopes - Merge branch 'master' into memory_session_cleanup - Fix issue in Direct-X-Buffer template - Simplify and drop the state class - Add missing files - Initial push ------------- Changes: https://git.openjdk.org/jdk19/pull/39/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=39&range=01 Stats: 577 lines in 28 files changed: 53 ins; 125 del; 399 mod Patch: https://git.openjdk.org/jdk19/pull/39.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/39/head:pull/39 PR: https://git.openjdk.org/jdk19/pull/39 From alanb at openjdk.org Mon Jul 11 14:43:49 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 11 Jul 2022 14:43:49 GMT Subject: Integrated: 8290002: (se) AssertionError in SelectorImpl.implCloseSelector In-Reply-To: References: Message-ID: <0gb0Zr1aXjqBbF4F-1NCHOWZWBc2FwzbaQ2xwOvVNXM=.26510fac-5fdc-459b-8985-5fb860ea2fd1@github.com> On Sun, 10 Jul 2022 06:54:56 GMT, Alan Bateman wrote: > This change adjusts an incorrect assert in the Selector implementation. The assert is incorrect since JDK 11 and JDK-8201315. The correct assert here is to test that the selector's selected-key set is empty. The selector's key set is not guaranteed to be empty here as there may be other threads registering channels while the selector is being closed. This pull request has now been integrated. Changeset: fc01666a Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/fc01666a5824d55b2549c81c0c3602aafdec693c Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8290002: (se) AssertionError in SelectorImpl.implCloseSelector Reviewed-by: michaelm ------------- PR: https://git.openjdk.org/jdk/pull/9442 From mcimadamore at openjdk.org Mon Jul 11 15:15:56 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 11 Jul 2022 15:15:56 GMT Subject: [jdk19] Withdrawn: 8288697: Clarify lifecycle of buffer segments and loader lookup In-Reply-To: References: Message-ID: <5LRXjtqv5kfiVtlsihxBScnttPrbSIMvNRRfrF2jwj4=.e9e9f559-7bb7-47a6-a6c4-91b1097d9bbe@github.com> On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore wrote: > This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases: > > * when a buffer segment is created, to keep the original buffer instance reachable > * when a loader symbol lookup is created, to keep the classloader instance reachable > > Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model. > > This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments. > > This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk19/pull/39 From jwilhelm at openjdk.org Mon Jul 11 16:19:55 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 11 Jul 2022 16:19:55 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 12:38:11 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: c79baaa8 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c79baaa811971c43fbdbc251482d0e40903588cc Stats: 411 lines in 43 files changed: 284 ins; 26 del; 101 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9450 From bpb at openjdk.org Mon Jul 11 21:35:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Jul 2022 21:35:03 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out Message-ID: Increase timeout value. ------------- Commit messages: - 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out Changes: https://git.openjdk.org/jdk19/pull/135/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=135&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290095 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/135.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/135/head:pull/135 PR: https://git.openjdk.org/jdk19/pull/135 From bpb at openjdk.org Mon Jul 11 21:35:04 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 11 Jul 2022 21:35:04 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 21:28:10 GMT, Brian Burkhalter wrote: > Increase timeout value. Recent failures show the test succeeding after the timeout handler has started. ------------- PR: https://git.openjdk.org/jdk19/pull/135 From jpai at openjdk.org Tue Jul 12 02:22:19 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 02:22:19 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out In-Reply-To: References: Message-ID: <4u02lnakgDi3vKMn1BcOQDD35RnoCpVB4oTMWdcKlx4=.05f17621-bfe3-429d-80de-7ee1a8fc8fc9@github.com> On Mon, 11 Jul 2022 21:28:10 GMT, Brian Burkhalter wrote: > Increase timeout value. test/jdk/java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java line 2: > 1: /* > 2: * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved. Hello Brian, there's a comma missing here after 2022. ------------- PR: https://git.openjdk.org/jdk19/pull/135 From bpb at openjdk.org Tue Jul 12 02:35:31 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Jul 2022 02:35:31 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v2] In-Reply-To: References: Message-ID: > Increase timeout value. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290095: Added missing comma in copyright header ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/135/files - new: https://git.openjdk.org/jdk19/pull/135/files/65ab7a18..acb5b20a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=135&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=135&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/135.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/135/head:pull/135 PR: https://git.openjdk.org/jdk19/pull/135 From bpb at openjdk.org Tue Jul 12 02:35:34 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Jul 2022 02:35:34 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v2] In-Reply-To: <4u02lnakgDi3vKMn1BcOQDD35RnoCpVB4oTMWdcKlx4=.05f17621-bfe3-429d-80de-7ee1a8fc8fc9@github.com> References: <4u02lnakgDi3vKMn1BcOQDD35RnoCpVB4oTMWdcKlx4=.05f17621-bfe3-429d-80de-7ee1a8fc8fc9@github.com> Message-ID: On Tue, 12 Jul 2022 02:19:20 GMT, Jaikiran Pai wrote: > Hello Brian, there's a comma missing here after 2022. Oops. Thanks! ------------- PR: https://git.openjdk.org/jdk19/pull/135 From jpai at openjdk.org Tue Jul 12 02:46:25 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 12 Jul 2022 02:46:25 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 02:35:31 GMT, Brian Burkhalter wrote: >> Increase timeout value. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290095: Added missing comma in copyright header Thank you Brian. Doubling the timeout looks fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk19/pull/135 From alanb at openjdk.org Tue Jul 12 05:56:44 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Jul 2022 05:56:44 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 02:35:31 GMT, Brian Burkhalter wrote: >> Increase timeout value. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290095: Added missing comma in copyright header Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/135 From duke at openjdk.org Tue Jul 12 06:50:29 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Tue, 12 Jul 2022 06:50:29 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 Message-ID: On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" HKEY_CLASSES_ROOT.js Content Type REG_SZ text/plain So, "text/plain" should be added for content type of ".js". I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. Could you review this fix, please? ------------- Commit messages: - 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 Changes: https://git.openjdk.org/jdk/pull/9459/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9459&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290149 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9459.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9459/head:pull/9459 PR: https://git.openjdk.org/jdk/pull/9459 From djelinski at openjdk.org Tue Jul 12 11:34:43 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 12 Jul 2022 11:34:43 GMT Subject: Integrated: 8289768: Clean up unused code In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski wrote: > This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. > > The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning. > > I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions. This pull request has now been integrated. Changeset: 04c47da1 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4 Stats: 98 lines in 46 files changed: 0 ins; 69 del; 29 mod 8289768: Clean up unused code Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar ------------- PR: https://git.openjdk.org/jdk/pull/9383 From jwilhelm at openjdk.org Tue Jul 12 13:02:41 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 12 Jul 2022 13:02:41 GMT Subject: RFR: Merge jdk19 Message-ID: <2YZUprz-2ZGbx7u2i3jBdnvJby6P1U10AT5PdRGBUpw=.6e72a7ee-78fc-4c77-bfee-0d0175c3be4c@github.com> Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8289148: j.l.foreign.VaList::nextVarg call could throw IndexOutOfBoundsException or even crash the VM - 8289709: fatal error: stuck in JvmtiVTMSTransitionDisabler::disable_VTMS_transitions - 8287902: UnreadableRB case in MissingResourceCauseTest is not working reliably on Windows - 8287379: Using @inheritDoc in an inapplicable context shouldn't crash javadoc - 8287809: Revisit implementation of memory session The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9467&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9467&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9467/files Stats: 1307 lines in 41 files changed: 485 ins; 330 del; 492 mod Patch: https://git.openjdk.org/jdk/pull/9467.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9467/head:pull/9467 PR: https://git.openjdk.org/jdk/pull/9467 From msheppar at openjdk.org Tue Jul 12 14:47:53 2022 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 12 Jul 2022 14:47:53 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 02:35:31 GMT, Brian Burkhalter wrote: >> Increase timeout value. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290095: Added missing comma in copyright header The existing time out of 4 minutes has (in mach5) a timeout factor of 4 applied to it such that the test is timing out after 16 minutes. This will now increase to 32 minutes, which will expand the running time of nio test runs and all other inclusive groupings. The extreme nature of the test and its high resource usage would suggest some special consideration as to when and how it is run ------------- PR: https://git.openjdk.org/jdk19/pull/135 From bpb at openjdk.org Tue Jul 12 21:02:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Jul 2022 21:02:06 GMT Subject: RFR: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension Message-ID: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. ------------- Commit messages: - 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the .rar extension Changes: https://git.openjdk.org/jdk/pull/9475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9475&range=00 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9475.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9475/head:pull/9475 PR: https://git.openjdk.org/jdk/pull/9475 From lancea at openjdk.org Tue Jul 12 21:02:07 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 12 Jul 2022 21:02:07 GMT Subject: RFR: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9475 From lancea at openjdk.org Tue Jul 12 21:11:00 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 12 Jul 2022 21:11:00 GMT Subject: RFR: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9475 From bpb at openjdk.org Tue Jul 12 23:38:31 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Jul 2022 23:38:31 GMT Subject: [jdk19] RFR: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out [v3] In-Reply-To: References: Message-ID: > Increase timeout value. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290095: Print some timestamps ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/135/files - new: https://git.openjdk.org/jdk19/pull/135/files/acb5b20a..b3704d01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=135&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=135&range=01-02 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/135.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/135/head:pull/135 PR: https://git.openjdk.org/jdk19/pull/135 From bpb at openjdk.org Tue Jul 12 23:38:32 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 12 Jul 2022 23:38:32 GMT Subject: [jdk19] Integrated: 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 21:28:10 GMT, Brian Burkhalter wrote: > Increase timeout value. This pull request has now been integrated. Changeset: 128c6c64 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk19/commit/128c6c648c24c37ab20a7c902d67d245e2b4ca72 Stats: 19 lines in 1 file changed: 17 ins; 0 del; 2 mod 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk19/pull/135 From dfuchs at openjdk.org Wed Jul 13 08:33:53 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 13 Jul 2022 08:33:53 GMT Subject: RFR: 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9475 From jpai at openjdk.org Wed Jul 13 11:09:06 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 13 Jul 2022 11:09:06 GMT Subject: RFR: 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. The change looks fine to me. On a related note, there is another PR which fixes a similar issue for a different extension type https://github.com/openjdk/jdk/pull/9459. This test has seen similar updates in recent past where we have been adding more such expected mime types to get the test passing. Reducing the number of file types we check here in this test might be a way to prevent these failures, but that too may not be a guaranteed way to prevent them. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9475 From alanb at openjdk.org Wed Jul 13 11:15:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Jul 2022 11:15:58 GMT Subject: RFR: 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. > On a related note, there is another PR which fixes a similar issue for a different extension type #9459. This test has seen similar updates in recent past where we have been adding more such expected mime types to get the test passing. Reducing the number of file types we check here in this test might be a way to prevent these failures, but that too may not be a guaranteed way to prevent them. I agree. The test originally tested a tiny set of MIME types but it was expanded greatly in recent releases and I think should be looked at again. ------------- PR: https://git.openjdk.org/jdk/pull/9475 From jpai at openjdk.org Wed Jul 13 11:58:05 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 13 Jul 2022 11:58:05 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya wrote: > On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. > > > C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" > > HKEY_CLASSES_ROOT.js > Content Type REG_SZ text/plain > > > So, "text/plain" should be added for content type of ".js". > > I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. > > Could you review this fix, please? I couldn't reproduce this neither on a Windows 2019 nor on a Windows 2022 system. However, the output of your command in the PR description does suggest that your system is configured to consider this "text/plain". Plus the documentation of `HKEY_CLASSES_ROOT` states that these values are per user configurable https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc739822(v=ws.10) Based on that, I think this change is fine and trivial. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/9459 From jpai at openjdk.org Wed Jul 13 12:02:59 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 13 Jul 2022 12:02:59 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: <0MZ51NtnHxI7kKCogslMCPzZ8XXgGKcm1bSUeeujgs8=.4e58f110-b8a7-4ec3-8489-163483cbec3f@github.com> On Wed, 13 Jul 2022 11:54:27 GMT, Jaikiran Pai wrote: > I couldn't reproduce this neither on a Windows 2019 nor on a Windows 2022 system. To be clear, my attempts were on a Windows Server 2019 and Windows Server 2022 versions. Reading your comment in the description of the JBS issue, the failures were on a Windows Standard edition. ------------- PR: https://git.openjdk.org/jdk/pull/9459 From lancea at openjdk.org Wed Jul 13 12:13:18 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 13 Jul 2022 12:13:18 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya wrote: > On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. > > > C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" > > HKEY_CLASSES_ROOT.js > Content Type REG_SZ text/plain > > > So, "text/plain" should be added for content type of ".js". > > I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. > > Could you review this fix, please? Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9459 From lancea at openjdk.org Wed Jul 13 12:13:19 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 13 Jul 2022 12:13:19 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: <0MZ51NtnHxI7kKCogslMCPzZ8XXgGKcm1bSUeeujgs8=.4e58f110-b8a7-4ec3-8489-163483cbec3f@github.com> References: <0MZ51NtnHxI7kKCogslMCPzZ8XXgGKcm1bSUeeujgs8=.4e58f110-b8a7-4ec3-8489-163483cbec3f@github.com> Message-ID: On Wed, 13 Jul 2022 11:59:26 GMT, Jaikiran Pai wrote: > > I couldn't reproduce this neither on a Windows 2019 nor on a Windows 2022 system. > > To be clear, my attempts were on a Windows Server 2019 and Windows Server 2022 versions. Reading your comment in the description of the JBS issue, the failures were on a Windows Standard edition. Yes some of these issues seem to be configuration specific to the OS and/or hardware which is why we see some of these failures only on select systems ------------- PR: https://git.openjdk.org/jdk/pull/9459 From jwilhelm at openjdk.org Wed Jul 13 12:22:55 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Wed, 13 Jul 2022 12:22:55 GMT Subject: RFR: Merge jdk19 Message-ID: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com> Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8290203: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java on linux-all - 8290201: ProblemList com/sun/jdi/InvokeHangTest.java on macosx-x64 in vthread mode - 8290095: java/nio/channels/FileChannel/largeMemory/LargeGatheringWrite.java timed out - 8289930: Improve Thread description of inherited AccessControlContext - 8289365: SegmentAllocator:allocateArray(MemoryLayout, count) does not throw IAEx when count is -1 - 8290071: Javadoc for MemorySegment/MemoryAddress getter/setters contains some typos - 8288850: SegmentAllocator:allocate() can return null some cases The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9479&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9479&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9479/files Stats: 120 lines in 9 files changed: 59 ins; 3 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/9479.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9479/head:pull/9479 PR: https://git.openjdk.org/jdk/pull/9479 From mkartashev at openjdk.org Wed Jul 13 14:13:16 2022 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Wed, 13 Jul 2022 14:13:16 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya wrote: > On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. > > > C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" > > HKEY_CLASSES_ROOT.js > Content Type REG_SZ text/plain > > > So, "text/plain" should be added for content type of ".js". > > I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. > > Could you review this fix, please? The test failed in exactly this fashion on my Windows 10 system; happy to see this resolved. ------------- PR: https://git.openjdk.org/jdk/pull/9459 From brian.burkhalter at oracle.com Wed Jul 13 15:15:59 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 13 Jul 2022 15:15:59 +0000 Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: <004EFCE6-FF48-4241-8067-C33397B335D6@oracle.com> On Jul 13, 2022, at 7:13 AM, Maxim Kartashev > wrote: On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya > wrote: On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" HKEY_CLASSES_ROOT.js Content Type REG_SZ text/plain So, "text/plain" should be added for content type of ".js". I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. Could you review this fix, please? The test failed in exactly this fashion on my Windows 10 system; happy to see this resolved. ------------- PR: https://git.openjdk.org/jdk/pull/9459 Two of us run the same version of macOS and one person saw the failure but the other did not. On the failing machine WinZip was installed and there was speculation that that might be the reason, i.e., it installs an additional MIME type. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Wed Jul 13 15:18:05 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Jul 2022 15:18:05 GMT Subject: Integrated: 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension In-Reply-To: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> References: <9S_qiacAaxvzJECDj5-t9FAy5QoWXCuQfMrqmTpesHc=.a4e8628e-c9b6-474d-82d3-6e5c75705e6e@github.com> Message-ID: <30f8DDZaVDnG4tiUxMIsFmlJ4hHqD-o76J1uu8mDkXI=.71ffe5ab-c547-42aa-af1d-fd1ed87a5909@github.com> On Tue, 12 Jul 2022 20:37:56 GMT, Brian Burkhalter wrote: > Add `application/x-rar-compressed` to the list of MIME types expected for the `rar` file extension. This pull request has now been integrated. Changeset: 44fb92e2 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/44fb92e2aa8a708b94c568e3d39217cb4c39f6bf Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290197: test/jdk/java/nio/file/Files/probeContentType/Basic.java fails on some systems for the ".rar" extension Reviewed-by: lancea, dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/9475 From bpb at openjdk.org Wed Jul 13 17:49:37 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Jul 2022 17:49:37 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir Message-ID: Attempt to make `FIleChannel` tests not run concurrently with each other. ------------- Commit messages: - 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir Changes: https://git.openjdk.org/jdk19/pull/139/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=139&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290252 Stats: 1 line in 3 files changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/139.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/139/head:pull/139 PR: https://git.openjdk.org/jdk19/pull/139 From bpb at openjdk.org Wed Jul 13 18:24:17 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Jul 2022 18:24:17 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v2] In-Reply-To: References: Message-ID: > Attempt to make `FIleChannel` tests not run concurrently with each other. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290252: Remove com/sun/net/httpserver/simpleserver from TEST.ROOT ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/139/files - new: https://git.openjdk.org/jdk19/pull/139/files/85ea6a55..1148e3a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=139&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=139&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/139.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/139/head:pull/139 PR: https://git.openjdk.org/jdk19/pull/139 From bpb at openjdk.org Wed Jul 13 18:26:32 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 13 Jul 2022 18:26:32 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v3] In-Reply-To: References: Message-ID: > Attempt to make `FIleChannel` tests not run concurrently with each other. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8290252: Remove java/nio/channels/FileChannel/largeMemory TEST.ROOT ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/139/files - new: https://git.openjdk.org/jdk19/pull/139/files/1148e3a2..554a9b89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=139&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=139&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/139.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/139/head:pull/139 PR: https://git.openjdk.org/jdk19/pull/139 From alanb at openjdk.org Wed Jul 13 19:03:12 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Jul 2022 19:03:12 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v3] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:26:32 GMT, Brian Burkhalter wrote: >> Attempt to make `FIleChannel` tests not run concurrently with each other. > > Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8290252: Remove java/nio/channels/FileChannel/largeMemory TEST.ROOT Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/139 From jpai at openjdk.org Thu Jul 14 03:29:20 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 14 Jul 2022 03:29:20 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v3] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:26:32 GMT, Brian Burkhalter wrote: >> Attempt to make `FIleChannel` tests not run concurrently with each other. > > Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8290252: Remove java/nio/channels/FileChannel/largeMemory TEST.ROOT Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/139 From jwilhelm at openjdk.org Thu Jul 14 06:23:49 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Thu, 14 Jul 2022 06:23:49 GMT Subject: Integrated: Merge jdk19 In-Reply-To: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com> References: <0kV4AZaoLszVYbNjgtP-POvZBo8IlSUi1DhF5G6YYrc=.b18a6389-52ff-4d1a-95de-f537f506fef4@github.com> Message-ID: On Wed, 13 Jul 2022 12:15:55 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: a7f83582 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/a7f83582d323b0dc39abc0b2114144206183af45 Stats: 120 lines in 9 files changed: 59 ins; 3 del; 58 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9479 From duke at openjdk.org Thu Jul 14 06:42:56 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 14 Jul 2022 06:42:56 GMT Subject: RFR: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: <5QXp9LCalXN47ljviSaWkPcPaS1wV1W0stsSQDNzfo8=.77ea0272-839c-4a81-a257-9efef16bb4a8@github.com> On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya wrote: > On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. > > > C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" > > HKEY_CLASSES_ROOT.js > Content Type REG_SZ text/plain > > > So, "text/plain" should be added for content type of ".js". > > I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. > > Could you review this fix, please? Thank you for your reviews. I hope this change is integrated if there are no problems. ------------- PR: https://git.openjdk.org/jdk/pull/9459 From duke at openjdk.org Thu Jul 14 07:04:57 2022 From: duke at openjdk.org (KIRIYAMA Takuya) Date: Thu, 14 Jul 2022 07:04:57 GMT Subject: Integrated: 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 06:41:35 GMT, KIRIYAMA Takuya wrote: > On Windows Server 2019/2022, default content type of ".js" is set to "text/plain" in registry. > > > C:\>reg query HKEY_CLASSES_ROOT.js /v "Content Type" > > HKEY_CLASSES_ROOT.js > Content Type REG_SZ text/plain > > > So, "text/plain" should be added for content type of ".js". > > I propose to add default registry value to expected list. After fix, test passes on Windows Server 2022. > > Could you review this fix, please? This pull request has now been integrated. Changeset: adf40d25 Author: KIRIYAMA Takuya Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/adf40d25a1c53ac4804d013c78558c58edb20b85 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290149: java/nio/file/Files/probeContentType/Basic.java fails on Windows Server 2019/2022 Reviewed-by: jpai, lancea ------------- PR: https://git.openjdk.org/jdk/pull/9459 From msheppar at openjdk.org Thu Jul 14 13:00:14 2022 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 14 Jul 2022 13:00:14 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v3] In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:26:32 GMT, Brian Burkhalter wrote: >> Attempt to make `FIleChannel` tests not run concurrently with each other. > > Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8290252: Remove java/nio/channels/FileChannel/largeMemory TEST.ROOT just curious as to why TEST.properties was added in test directory java/nio/channels/FileChannel rather than amending the TEST.ROOT java/nio/channels/FileChannel/largeMemory entry to java/nio/channels/FileChannel to get exclusive non current execution ? ------------- PR: https://git.openjdk.org/jdk19/pull/139 From alanb at openjdk.org Thu Jul 14 13:11:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Jul 2022 13:11:58 GMT Subject: [jdk19] RFR: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir [v3] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 12:56:32 GMT, Mark Sheppard wrote: > just curious as to why TEST.properties was added in test directory java/nio/channels/FileChannel rather than amending the TEST.ROOT java/nio/channels/FileChannel/largeMemory entry to java/nio/channels/FileChannel to get exclusive non current execution ? Personally I think it is easier to find when it's the same directory has the tests. There are currently >90 TEST.properties files in the test/jdk tree, but you are right that it could work both ways. ------------- PR: https://git.openjdk.org/jdk19/pull/139 From bpb at openjdk.org Thu Jul 14 15:26:17 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 14 Jul 2022 15:26:17 GMT Subject: [jdk19] Integrated: 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir In-Reply-To: References: Message-ID: <5aB626gyMY003m6hJMhg4ximzo_eJAutlHcfOZU5Kn8=.bc3a3243-def5-4802-a052-6ccf126143ca@github.com> On Wed, 13 Jul 2022 17:40:48 GMT, Brian Burkhalter wrote: > Attempt to make `FIleChannel` tests not run concurrently with each other. This pull request has now been integrated. Changeset: fb27ddcb Author: Brian Burkhalter URL: https://git.openjdk.org/jdk19/commit/fb27ddcbe5a503ddd841e55baaa9a10f8422b736 Stats: 3 lines in 4 files changed: 0 ins; 1 del; 2 mod 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk19/pull/139 From bpb at openjdk.org Thu Jul 14 17:23:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 14 Jul 2022 17:23:44 GMT Subject: RFR: 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods Message-ID: Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. ------------- Commit messages: - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods Changes: https://git.openjdk.org/jdk/pull/9486/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8264744 Stats: 288 lines in 4 files changed: 279 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9486.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486 PR: https://git.openjdk.org/jdk/pull/9486 From bpb at openjdk.org Thu Jul 14 17:23:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 14 Jul 2022 17:23:44 GMT Subject: RFR: 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 23:25:00 GMT, Brian Burkhalter wrote: > Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. On Linux, the `copy_file_range(2)` system call already includes file cloning if available, so there is no need to add an explicit call to `ioctl(2)` with request code `FICLONE` or `FICLONERANGE` unless `copy_file_range()` is unavailable. Therefore the Linux `ioctl_ficlone` branch in `cloneFile0()` is conditional, and an invocation of `copy_file_range()` is prepended in `directCopy0()` on Linux. Note that as `FileChannel::transferFrom` was already calling `copy_file_range()`, it was already using cloning on Linux when possible. On macOS, the available cloning system calls are `clonefile(2)` and `copyfile(3)` with for the latter `COPYFILE_CLONE` set in `flags`. There is no cloning call which accepts file descriptors as the target cannot already exist when the system call is invoked. There is also no call on macOS to clone a range of a file, hence there is no cloning added for `transferFrom()` nor `transferTo()` on macOS. The througput of `Files::copy` is greatly increased by using cloning, at the expense of course of the first subsequent write to the target path being slower due to copy-on-write (CoW). throughput (ops/s) APFS (macOS) BTRFS (Linux) EXT4 (Linux) count before after before after before after 10240 1578.971 2902.128 24331.624 31074.073 27722.815 27574.891 51200 1849.027 2917.996 19295.797 31313.13 18590.463 18650.098 102400 1757.527 2899.018 15874.133 31243.225 13242.939 13235.246 512000 1195.215 2818.547 5856.964 30972.607 3998.696 3903.092 1048568 829.433 2169.738 3283.841 31097.633 2056.693 2014.939 10485760 126.736 2336.032 236.58 30754.849 154.103 153.356 104857600 15.014 2361.208 22.352 31123.14 14.864 14.746 1073741824 2.484 2335.799 1.549 30682.197 1.408 1.41 The throughput within a CoW file system (APFS and BTRFS) is much higher, especially for large files, and that within a non-CoW file system (EXT4) is effectively unchanged. As APFS supports CoW, existing tests should cover these changes. For Linux, a dynamic search for file systems supporting CoW is added in the `CopyAndMove` test. It is unclear whether the Linux branch in `cloneFile0` should attempt to use `ioctl_ficlone` if `copy_file_range` is undefined, as currently proposed, or simply always return `IOS_UNAVAILABLE`. It is likewise unclear whether `ioctl_ficlonerange` should be used in `transferFrom0` and `transferTo0` if `copy_file_range` is undefined (it currently is not). In the initial version of this patch, cloning is enabled by default. In the issue description the possibility of adding a (JDK-specific?) `CopyOption` or system property to disable cloning was mentioned. There is also the opposite approach of cloning being disabled by default, with a `CopyOption` or system property required to enable it. ------------- PR: https://git.openjdk.org/jdk/pull/9486 From alanb at openjdk.org Thu Jul 14 17:42:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Jul 2022 17:42:02 GMT Subject: RFR: 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 23:25:00 GMT, Brian Burkhalter wrote: > Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. This is good work but it is putting a lot of platform specific code in UnixCopyFile. I think we'll need to some up front refactoring to support this so that the copy_file_range and clonefile implementation are Linux and macOS specific source files. This should allow more of the code to be written in Java and will allow most of the native code to go away. ------------- PR: https://git.openjdk.org/jdk/pull/9486 From duke at openjdk.org Thu Jul 14 23:53:05 2022 From: duke at openjdk.org (duke) Date: Thu, 14 Jul 2022 23:53:05 GMT Subject: Withdrawn: 8190546: File.toPath() reject directory names with trailing space In-Reply-To: References: Message-ID: On Thu, 19 May 2022 13:11:11 GMT, Maxim Kartashev wrote: > [JDK-8190546](https://bugs.openjdk.java.net/browse/JDK-8190546) is currently closed as will-not-fix with a reference to Win32 documentation [1] that kind of discourages the use of space at the very end of a file name. That documentation says the following: > >> Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not > > > Indeed, it's hard or even impossible to create such a file using the "normal" windows GUI, but you can use that GUI to _delete_ such a file. In Java, you can't do either. > > I'm proposing to lift this restriction primarily based on our user's requests and one or two use cases that seem legitimate. > > Working in a cygwin terminal, you can fairly easily create a file name ending with a space. And when you turn to your Java-based IDE to delete it, you get an error from the very basic level of NIO that you can't overrule, which seems to be quite unfortunate. Another source of files legitimately ending with a space would be any Unix filesystem accessed from a Windows Java application (be that a local `\\wsl$` or a NFS mounted from a remote machine). > > If you are interested in moving forward with the issue, please review the PR. Thank you! > > References > [1] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8788 From bpb at openjdk.org Fri Jul 15 02:30:00 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 15 Jul 2022 02:30:00 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v2] In-Reply-To: References: Message-ID: > Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264744: Refactor into provider+dispatcher to reduce amount of JNI code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9486/files - new: https://git.openjdk.org/jdk/pull/9486/files/35ed61e2..d2a862c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=00-01 Stats: 336 lines in 10 files changed: 195 ins; 125 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9486.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486 PR: https://git.openjdk.org/jdk/pull/9486 From alanb at openjdk.org Fri Jul 15 10:16:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 10:16:02 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v2] In-Reply-To: References: Message-ID: <7RKdytGAzM74FgNvcGYuyt_AzR0w-vccuzM39LHezl4=.34ff4e2a-2b70-424a-9132-3d3f2a8a103f@github.com> On Fri, 15 Jul 2022 02:30:00 GMT, Brian Burkhalter wrote: >> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264744: Refactor into provider+dispatcher to reduce amount of JNI code This version looks much better but I think it will need another round of two to get the code into the right place. As it stands, the change mean that some of the macOS specific file copy code is in UnixCopyFile and the reset is in BsdNativeDispatcher. For macOS I suspect we'll end up with BsdCopyFile extending UnixCopyFile add adding support for fcopyfile and clonefile. Similarly LinuxCopyFile will extend UnixCopyFile and add support for copy_file_range. A few specific issues on this version: - LinuxFileSystemProvider.clone leaks a file descriptor if creating the target file fails - LinuxFileSystemProvider.clone checks if the file exists but that check doesn't make sense here - LinuxNativeDispatcher.ioctl_ficlone uses Blocker but I would have expected that in the caller, not here - BsdFileSystemProvider.clone uses noFollowLinks. I think it would be clearer everywhere to invert that to followLinks. It may be better to map it to the flag at the Java level too. - I wonder if FICLONE is available at build time to avoid the hardcoded value (main concern is whether it has the same value on all Linux ports) ------------- PR: https://git.openjdk.org/jdk/pull/9486 From duke at openjdk.org Fri Jul 15 11:33:09 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 15 Jul 2022 11:33:09 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 02:30:00 GMT, Brian Burkhalter wrote: >> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264744: Refactor into provider+dispatcher to reduce amount of JNI code I really appreciate all I/O performance improvements, in particular offloading to OS and FS! :-) test/jdk/java/nio/file/Files/CopyAndMove.java line 52: > 50: // for testing cloning / reflink on Linux > 51: private static final Set COW_TYPES = > 52: Set.of("bcachefs", "btrfs", "ocfs2", "xfs"); Shouldn't we also test on non-CoW-FS to be sure that the recent changes do not have a negative impact *there*? ------------- Marked as reviewed by mkarg at github.com (no known OpenJDK username). PR: https://git.openjdk.org/jdk/pull/9486 From duke at openjdk.org Fri Jul 15 12:10:32 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:10:32 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable Message-ID: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Simplify code with `String.join()` ------------- Commit messages: - 8290300: Fix copy-right year - 8290300: Use standard String-joining tools where applicable Changes: https://git.openjdk.org/jdk/pull/9513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290300 Stats: 90 lines in 8 files changed: 1 ins; 68 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From jlaskey at openjdk.org Fri Jul 15 12:28:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 15 Jul 2022 12:28:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` LGTM, however are there tests that ensure the changes are benign? ------------- PR: https://git.openjdk.org/jdk/pull/9513 From alanb at openjdk.org Fri Jul 15 12:33:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Jul 2022 12:33:48 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` joptsimple is a 3rd party code so we probably don't want to change that. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: - 8290300: Revert jops - 8290300: Revert jops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/f3020263..80384470 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=00-01 Stats: 73 lines in 4 files changed: 58 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? wrote: > Simplify code with `String.join()` Reverted jops ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Fri Jul 15 12:40:50 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 15 Jul 2022 12:40:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8290300: Revert jops >> - 8290300: Revert jops > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey I'll double check and add tests if necessary ------------- PR: https://git.openjdk.org/jdk/pull/9513 From bpb at openjdk.org Fri Jul 15 14:57:02 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 15 Jul 2022 14:57:02 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 02:30:00 GMT, Brian Burkhalter wrote: >> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8264744: Refactor into provider+dispatcher to reduce amount of JNI code I agree about having OS-specific `CopyFile` classes instead of OS-specific providers. I don?t like the `IOStatus` being in the provider and the call of `provider.clone()` seems odd. - `LinuxNativeDispatcher.ioctl_ficlone` uses `Blocker` emulating the calls in `UnixNativeDispatcher`. - `FICLONE` is the descendent of `BTRFS_IOC_CLONE` and has the same numerical value so I think it is fairly safe. Agreed about the other points. ------------- PR: https://git.openjdk.org/jdk/pull/9486 From bpb at openjdk.org Fri Jul 15 14:57:04 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 15 Jul 2022 14:57:04 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v2] In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:28:38 GMT, Markus KARG wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8264744: Refactor into provider+dispatcher to reduce amount of JNI code > > test/jdk/java/nio/file/Files/CopyAndMove.java line 52: > >> 50: // for testing cloning / reflink on Linux >> 51: private static final Set COW_TYPES = >> 52: Set.of("bcachefs", "btrfs", "ocfs2", "xfs"); > > Shouldn't we also test on non-CoW-FS to be sure that the recent changes do not have a negative impact *there*? Most testing is done on ext4 so this is covered. ------------- PR: https://git.openjdk.org/jdk/pull/9486 From bpb at openjdk.org Fri Jul 15 15:58:54 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 15 Jul 2022 15:58:54 GMT Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of FileChannel transfer and Files copy methods [v3] In-Reply-To: References: Message-ID: > Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8264744: Address review comments aside from refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9486/files - new: https://git.openjdk.org/jdk/pull/9486/files/d2a862c4..6f3e4517 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=01-02 Stats: 87 lines in 7 files changed: 47 ins; 14 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/9486.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486 PR: https://git.openjdk.org/jdk/pull/9486 From naoto at openjdk.org Fri Jul 15 16:31:46 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 15 Jul 2022 16:31:46 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v2] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4lc5aVxpfSL9ukqHt2IDLR_LQDkQx-3htusBXQDsx1I=.9c453024-986b-4828-9775-f5a1561d0097@github.com> On Fri, 15 Jul 2022 12:40:50 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision: > > - 8290300: Revert jops > - 8290300: Revert jops Changes to `Locale` look good to me. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9513 From jwilhelm at openjdk.org Sat Jul 16 12:36:44 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 16 Jul 2022 12:36:44 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8281969: Bad result for the snippet @link tag if substring/regex consists of whitespace - 8290250: Shenandoah: disable Loom for iu mode - 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9526/files Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9526.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9526/head:pull/9526 PR: https://git.openjdk.org/jdk/pull/9526 From jwilhelm at openjdk.org Sun Jul 17 15:15:03 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sun, 17 Jul 2022 15:15:03 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 12:26:23 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 522b6574 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/522b65743ca10fcba0a27d25b8fa11319999e228 Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9526 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <6NKq2IAULEe2WYW2aIEOvu9-8_p4aKtrW1ZFRJo16mc=.17712761-2483-49b4-acf4-2faa394a1a99@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused piece of code in formatList() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/80384470..4f2bbfd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:17:37 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:17:37 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v3] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Fri, 15 Jul 2022 12:25:07 GMT, Jim Laskey wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290300: Remove unused piece of code in formatList() > > LGTM, however are there tests that ensure the changes are benign? @JimLaskey changes in `WindowsPath` are covered by `PathOps`, apart from this there are 10 tests calling this method. With `ProcessBuilder` and `Locale` it looks like the code I've changed is never executed at all for `ProcessStartEvent.isEnabled()` always return false. For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, but I'm not sure about `ProcessBuilder`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 11:31:59 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 11:31:59 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/4f2bbfd3..5b18c39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From naoto at openjdk.org Mon Jul 18 16:49:45 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 16:49:45 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:08:24 GMT, ?????? ??????? wrote: > For `Locale` all the call sites of `formatList()` never pass null, so the code in `if` block is never executed. I think we can delete this unused parts of the code in `Locale`, Are you sure about this? `pattern` is derived from `LocaleResources.getLocaleName()` which could return `null`. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> > Simplify code with `String.join()` ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8290300: Revert erroneous changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9513/files - new: https://git.openjdk.org/jdk/pull/9513/files/5b18c39c..af555897 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9513&range=03-04 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9513.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9513/head:pull/9513 PR: https://git.openjdk.org/jdk/pull/9513 From duke at openjdk.org Mon Jul 18 18:40:51 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 18 Jul 2022 18:40:51 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v4] In-Reply-To: References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> Message-ID: On Mon, 18 Jul 2022 11:31:59 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Remove unused import Right, my bad. I've confused arguments. The changes reverted. ------------- PR: https://git.openjdk.org/jdk/pull/9513 From naoto at openjdk.org Mon Jul 18 18:56:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 18 Jul 2022 18:56:50 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <9nxXC6TKJOwD19iPW3lSojz6aWMT91DCTH3rrqx4C-8=.d43bb635-f3b1-4ebf-8baa-7b85078b7694@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From rriggs at openjdk.org Mon Jul 18 19:10:11 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 18 Jul 2022 19:10:11 GMT Subject: RFR: 8290300: Use standard String-joining tools where applicable [v5] In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com> <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com> Message-ID: <4MM9EyQBrfbebIry8tPi_LRPHaRGPbmVYp7xwf0hewQ=.6ae982ac-d33f-49f0-927c-f574c148ec35@github.com> On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? wrote: >> Simplify code with `String.join()` > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8290300: Revert erroneous changes Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9513 From shade at openjdk.org Tue Jul 19 13:00:28 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Jul 2022 13:00:28 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply Message-ID: Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: # release before real 4m41.424s user 24m18.064s sys 1m16.440s # release after real 2m47.769s ; -40% user 23m44.622s sys 1m15.240s # fastdebug before real 5m38.078s user 67m23.516s sys 1m56.446s # fastdebug after real 4m9.249s ; -26% user 67m21.940s sys 1m57.625s ------------- Commit messages: - More fixes - Fix Changes: https://git.openjdk.org/jdk/pull/9554/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9554&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290531 Stats: 34 lines in 2 files changed: 19 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9554.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9554/head:pull/9554 PR: https://git.openjdk.org/jdk/pull/9554 From maxxedev at gmail.com Wed Jul 20 17:16:50 2022 From: maxxedev at gmail.com (maxxedev at gmail.com) Date: Wed, 20 Jul 2022 10:16:50 -0700 Subject: Real path of soft links with missing target Message-ID: Hi, How can one resolve the real path of a soft link where the target file does not exist? For example, given: $ ln -s foo-target foo-source then this code throws an exception: Paths.get("foo-source").toRealPath(); Exception in thread "main" java.nio.file.NoSuchFileException: foo-source at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) at java.base/sun.nio.fs.UnixPath.toRealPath(UnixPath.java:860) at App.main(App.java:33) The underlying native code[1] reads like this: if (realpath(path, resolved) == NULL) { throwUnixException(env, errno); } However, it appears that realpath() does save the result in "resolved" argument even when the return value is null: #include #include #include #include int main(int argc, char** argv) { char* path = "foo-source"; char resolved[PATH_MAX + 1] = {0}; char* result = realpath(path, resolved); printf("%d\n", result == NULL); // 1 printf("%d\n", errno == ENOENT); // 1 printf("%s\n", resolved); // "foo-target" return 0; } Would it be possible to expose that behavior in Java, perhaps with a new LinkOption value to Path::toRealPath? Note though that realpath() specification[2] says the content of "resolved" argument is undefined if return value is null. Thanks [1] https://github.com/openjdk/jdk/blob/jdk-20%2B6/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c#L965-L966 [2] https://pubs.opengroup.org/onlinepubs/009696799/functions/realpath.html From brian.burkhalter at oracle.com Wed Jul 20 17:41:51 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 20 Jul 2022 17:41:51 +0000 Subject: Real path of soft links with missing target In-Reply-To: References: Message-ID: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> On Jul 20, 2022, at 10:16 AM, maxxedev at gmail.com wrote: #include #include #include #include int main(int argc, char** argv) { char* path = "foo-source"; char resolved[PATH_MAX + 1] = {0}; char* result = realpath(path, resolved); printf("%d\n", result == NULL); // 1 printf("%d\n", errno == ENOENT); // 1 printf("%s\n", resolved); // "foo-target" return 0; } When I run the above code in /tmp/ on Ubuntu 22.04 as $ ln -s foo-target foo-source $ ./resolve it prints 1 1 /tmp/foo-target As realpath(3) states ?[If there is an error, ] it returns NULL, the contents of the array resolved_path are undefined, and errno is set to indicate the error.? I don?t think one can rely on resolved_path or the return value when there is an error so I don?t know what we could do here. That resolved_path ends up being the link seems like an artifact that one cannot count on. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxxedev at gmail.com Wed Jul 20 18:19:20 2022 From: maxxedev at gmail.com (maxxedev at gmail.com) Date: Wed, 20 Jul 2022 11:19:20 -0700 Subject: Real path of soft links with missing target In-Reply-To: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> References: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> Message-ID: Ah, how about readlink[3]? #include #include #include #include #include int main(int argc, char** argv) { char* path = "foo-source"; char resolved[PATH_MAX + 1] = {0}; printf("%d\n", readlink(path, resolved, sizeof(resolved))); // 10 bytes printf("%d\n", errno); // 0 printf("%s\n", resolved); // "foo-target" return 0; } Motivation is: how could one replicate "ls -l" functionality in Java? "ls -l" does show the link target even if it's missing. [3] https://pubs.opengroup.org/onlinepubs/009696699/functions/readlink.html On Wed, Jul 20, 2022 at 10:41 AM Brian Burkhalter wrote: > > > On Jul 20, 2022, at 10:16 AM, maxxedev at gmail.com wrote: > > #include > #include > #include > #include > > int main(int argc, char** argv) { > char* path = "foo-source"; > char resolved[PATH_MAX + 1] = {0}; > char* result = realpath(path, resolved); > printf("%d\n", result == NULL); // 1 > printf("%d\n", errno == ENOENT); // 1 > printf("%s\n", resolved); // "foo-target" > return 0; > } > > > When I run the above code in /tmp/ on Ubuntu 22.04 as > > $ ln -s foo-target foo-source > $ ./resolve > > it prints > > 1 > 1 > /tmp/foo-target > > As realpath(3) states > > ?[If there is an error, ] it returns NULL, the contents of the array resolved_path are undefined, and errno is set to indicate the error.? > > I don?t think one can rely on resolved_path or the return value when there is an error so I don?t know what we could do here. That resolved_path ends up being the link seems like an artifact that one cannot count on. > > Brian > > > From roger.riggs at oracle.com Wed Jul 20 18:31:29 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 20 Jul 2022 14:31:29 -0400 Subject: Real path of soft links with missing target In-Reply-To: References: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> Message-ID: <1c586564-0455-36ac-e1a7-841a56f2a9bf@oracle.com> Hi, If realpath fails, there is no actual file with that path. The application could fallback to reading the symbolic link and then it would know the difference. $.02, Roger On 7/20/22 2:19 PM, maxxedev at gmail.com wrote: > Ah, how about readlink[3]? > > #include > #include > #include > #include > #include > > int main(int argc, char** argv) { > char* path = "foo-source"; > char resolved[PATH_MAX + 1] = {0}; > printf("%d\n", readlink(path, resolved, sizeof(resolved))); // 10 bytes > printf("%d\n", errno); // 0 > printf("%s\n", resolved); // "foo-target" > return 0; > } > > Motivation is: how could one replicate "ls -l" functionality in Java? > "ls -l" does show the link target even if it's missing. > > [3] https://pubs.opengroup.org/onlinepubs/009696699/functions/readlink.html > > > On Wed, Jul 20, 2022 at 10:41 AM Brian Burkhalter > wrote: >> >> On Jul 20, 2022, at 10:16 AM, maxxedev at gmail.com wrote: >> >> #include >> #include >> #include >> #include >> >> int main(int argc, char** argv) { >> char* path = "foo-source"; >> char resolved[PATH_MAX + 1] = {0}; >> char* result = realpath(path, resolved); >> printf("%d\n", result == NULL); // 1 >> printf("%d\n", errno == ENOENT); // 1 >> printf("%s\n", resolved); // "foo-target" >> return 0; >> } >> >> >> When I run the above code in /tmp/ on Ubuntu 22.04 as >> >> $ ln -s foo-target foo-source >> $ ./resolve >> >> it prints >> >> 1 >> 1 >> /tmp/foo-target >> >> As realpath(3) states >> >> ?[If there is an error, ] it returns NULL, the contents of the array resolved_path are undefined, and errno is set to indicate the error.? >> >> I don?t think one can rely on resolved_path or the return value when there is an error so I don?t know what we could do here. That resolved_path ends up being the link seems like an artifact that one cannot count on. >> >> Brian >> >> >> From djelinski at openjdk.org Wed Jul 20 19:49:27 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 20 Jul 2022 19:49:27 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header Message-ID: This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. Testing performed (with IP_DONTFRAGMENT flag): Windows 10: With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. For other systems I could not capture packets, so I can only report the observed behavior of sending packets. Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. If a packet is sent to a non-routable address, send succeeds, no error is reported. Linux: With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. Mac OS X 12: Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. ------------- Commit messages: - Revert test - Fix retrieval of dontfragment flag - Improve dontfragment handling on dual stack sockets Changes: https://git.openjdk.org/jdk/pull/9575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290349 Stats: 136 lines in 9 files changed: 2 ins; 66 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/9575.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9575/head:pull/9575 PR: https://git.openjdk.org/jdk/pull/9575 From brian.burkhalter at oracle.com Wed Jul 20 19:58:39 2022 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 20 Jul 2022 19:58:39 +0000 Subject: Real path of soft links with missing target In-Reply-To: References: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> Message-ID: On Jul 20, 2022, at 11:19 AM, maxxedev at gmail.com wrote: Motivation is: how could one replicate "ls -l" functionality in Java? "ls -l" does show the link target even if it's missing. How about https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/nio/file/Files.html#readSymbolicLink(java.nio.file.Path)? Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxxedev at gmail.com Wed Jul 20 20:03:07 2022 From: maxxedev at gmail.com (maxxedev at gmail.com) Date: Wed, 20 Jul 2022 13:03:07 -0700 Subject: Real path of soft links with missing target In-Reply-To: References: <70E50A75-33F0-4718-89E8-015071ADBA55@oracle.com> Message-ID: Ah, that works! Thanks! On Wed, Jul 20, 2022 at 12:58 PM Brian Burkhalter wrote: > > > > On Jul 20, 2022, at 11:19 AM, maxxedev at gmail.com wrote: > > Motivation is: how could one replicate "ls -l" functionality in Java? > "ls -l" does show the link target even if it's missing. > > > How about https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/nio/file/Files.html#readSymbolicLink(java.nio.file.Path)? > > Brian From jpai at openjdk.org Thu Jul 21 14:49:04 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 21 Jul 2022 14:49:04 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: Message-ID: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> On Wed, 20 Jul 2022 17:19:50 GMT, Daniel Jeli?ski wrote: > This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. > > All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. > > On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. > > As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. > > Testing performed (with IP_DONTFRAGMENT flag): > Windows 10: > With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. > Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. > > For other systems I could not capture packets, so I can only report the observed behavior of sending packets. > Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. > If a packet is sent to a non-routable address, send succeeds, no error is reported. > > Linux: > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. > > Mac OS X 12: > Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: > 205: } > 206: } > 207: return JNI_TRUE; Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? ------------- PR: https://git.openjdk.org/jdk/pull/9575 From bpb at openjdk.org Thu Jul 21 15:54:29 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 15:54:29 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length Message-ID: For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check int pos = syntaxAndInput.indexOf(':'); if (pos <= 0 || pos == syntaxAndInput.length()) to if (pos <= 0) ------------- Commit messages: - 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length Changes: https://git.openjdk.org/jdk/pull/9595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290047 Stats: 5 lines in 4 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From naoto at openjdk.org Thu Jul 21 17:03:50 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 21 Jul 2022 17:03:50 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter wrote: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Looks good, Brian. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 17:17:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 17:17:48 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter wrote: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: > 176: public PathMatcher getPathMatcher(String syntaxAndInput) { > 177: int pos = syntaxAndInput.indexOf(':'); > 178: if (pos <= 0 || pos == syntaxAndInput.length()) { Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. That would then throw if there was no string after the syntax selector; for example "glob:" ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 17:17:48 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 17:17:48 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 17:10:12 GMT, Roger Riggs wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: > >> 176: public PathMatcher getPathMatcher(String syntaxAndInput) { >> 177: int pos = syntaxAndInput.indexOf(':'); >> 178: if (pos <= 0 || pos == syntaxAndInput.length()) { > > Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. > That would then throw if there was no string after the syntax selector; for example "glob:" You have a point there. It does not want the ":" to be at the first position so it should not want it at the last position as the "pattern" part of the string would be empty. That fits with the specification IllegalArgumentException.html - If the parameter does not take the form: syntax:pattern ------------- PR: https://git.openjdk.org/jdk/pull/9595 From djelinski at openjdk.org Thu Jul 21 17:45:06 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 21 Jul 2022 17:45:06 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> References: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> Message-ID: On Thu, 21 Jul 2022 14:46:58 GMT, Jaikiran Pai wrote: >> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. >> >> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. >> >> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. >> >> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. >> >> Testing performed (with IP_DONTFRAGMENT flag): >> Windows 10: >> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. >> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. >> >> For other systems I could not capture packets, so I can only report the observed behavior of sending packets. >> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): >> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. >> If a packet is sent to a non-routable address, send succeeds, no error is reported. >> >> Linux: >> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. >> >> Mac OS X 12: >> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. > > src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: > >> 205: } >> 206: } >> 207: return JNI_TRUE; > > Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? Hi Jaikiran, the point of this change was to better support systems where either IPv4 or IPv6 was disabled. I'm not sure if that can even happen on Mac. The change here is that if we can't create one socket, we don't immediately return false, but instead return the result for the other socket. For example, if creating IPv4 socket fails, we only check if DF is supported on IPv6 socket, and return that as a result. If both `socket` calls fail, we don't know if the DF flag is supported, and return true (before the patch we would return false in that case). I can modify the patch to return false in that case, or roll back this change entirely if you think it makes no sense. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From bpb at openjdk.org Thu Jul 21 18:29:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:29:03 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: Message-ID: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290047: Ensure that colon is not at the last index ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9595/files - new: https://git.openjdk.org/jdk/pull/9595/files/291ef674..5765fa1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=00-01 Stats: 55 lines in 8 files changed: 43 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 18:31:24 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:31:24 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 17:13:58 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java line 178: >> >>> 176: public PathMatcher getPathMatcher(String syntaxAndInput) { >>> 177: int pos = syntaxAndInput.indexOf(':'); >>> 178: if (pos <= 0 || pos == syntaxAndInput.length()) { >> >> Is this really a different bug? Should it be checking for `length() - 1` to throw IAE. >> That would then throw if there was no string after the syntax selector; for example "glob:" > > You have a point there. It does not want the ":" to be at the first position so it should not want it at the last position as the "pattern" part of the string would be empty. That fits with the specification > > IllegalArgumentException.html - If the parameter does not take the form: syntax:pattern Corrected in 5765fa1c6883575da57499c7b70f6626443d869d. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From naoto at openjdk.org Thu Jul 21 18:41:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 21 Jul 2022 18:41:09 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:29:03 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Ensure that colon is not at the last index src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: > 742: } > 743: } catch (Throwable x) { > 744: System.out.println("Caught " + x); Leftover debug output? src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: > 747: exc = x; > 748: } finally { > 749: System.out.println("finally"); As above ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 18:46:07 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 18:46:07 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:36:57 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290047: Ensure that colon is not at the last index > > src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: > >> 742: } >> 743: } catch (Throwable x) { >> 744: System.out.println("Caught " + x); > > Leftover debug output? Yes, thanks for catching. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From rriggs at openjdk.org Thu Jul 21 18:56:13 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Jul 2022 18:56:13 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:29:03 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Ensure that colon is not at the last index Please update the issue title and description and PR title and description to match the new understanding. The IAE message in JrtFileSystem wording is a bit like it is leftover debugging output. The messages for all 4 IAE could be something as simple as "missing pattern". ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:09:08 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:09:08 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher needlessly checks syntaxAndInput.length [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:37:25 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8290047: Ensure that colon is not at the last index > > src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: > >> 747: exc = x; >> 748: } finally { >> 749: System.out.println("finally"); > > As above This file was a leftover from a different issue I was looking at and was accidentally included here. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:17:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:17:03 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:54:04 GMT, Roger Riggs wrote: > The IAE message in JrtFileSystem wording is a bit like it is leftover debugging output. The messages for all 4 IAE could be something as simple as "missing pattern". Not sure a message is needed. At the other extreme one could say "missing syntax" for ":pattern" and "missing pattern" for "syntax:". Or it could be "Parameter does not take the form: syntax:pattern". ------------- PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:58:50 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:58:50 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v3] In-Reply-To: References: Message-ID: > For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check > > int pos = syntaxAndInput.indexOf(':'); > if (pos <= 0 || pos == syntaxAndInput.length()) > > to > > if (pos <= 0) Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8290047: Remove IAE message in JrtFileSystem.getPathMatcher() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9595/files - new: https://git.openjdk.org/jdk/pull/9595/files/5765fa1c..ff404d4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9595&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9595.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595 PR: https://git.openjdk.org/jdk/pull/9595 From bpb at openjdk.org Thu Jul 21 19:58:51 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 21 Jul 2022 19:58:51 GMT Subject: RFR: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v2] In-Reply-To: References: <_MynhhG0hzRTOLCt6G7aYPWkIHPXnxU5t0qg3v4RDuU=.64ab38de-ca48-43ea-bb04-eeb2b4612a58@github.com> Message-ID: On Thu, 21 Jul 2022 18:42:40 GMT, Brian Burkhalter wrote: >> src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 744: >> >>> 742: } >>> 743: } catch (Throwable x) { >>> 744: System.out.println("Caught " + x); >> >> Leftover debug output? > > Yes, thanks for catching. Fixed in ff404d4b52c5ecf4f00743be1d4d4a266483460c. >> src/java.base/unix/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java line 749: >> >>> 747: exc = x; >>> 748: } finally { >>> 749: System.out.println("finally"); >> >> As above > > This file was a leftover from a different issue I was looking at and was accidentally included here. Fixed in ff404d4b52c5ecf4f00743be1d4d4a266483460c. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From shade at openjdk.org Fri Jul 22 07:05:49 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 22 Jul 2022 07:05:49 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <2O9J5hTXHGy-FGAlYrUvSOTAMz0SBpX4d3ROlvwJKRI=.655df335-0e24-4e84-8a03-c083a336eaf0@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Any comments, @pron, @AlanBateman? ------------- PR: https://git.openjdk.org/jdk/pull/9554 From rpressler at openjdk.org Fri Jul 22 11:56:04 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 22 Jul 2022 11:56:04 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s The changes to Fuzz.java seem fine to me. ------------- Marked as reviewed by rpressler (Committer). PR: https://git.openjdk.org/jdk/pull/9554 From michaelm at openjdk.org Mon Jul 25 10:55:04 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 25 Jul 2022 10:55:04 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: Message-ID: <1Flj2PO4zcxQgpmfZ3aw29S4PV5Wb1AyGs835PUezy8=.ba1e88f3-15c2-4e61-808b-d301ab372ec8@github.com> On Wed, 20 Jul 2022 17:19:50 GMT, Daniel Jeli?ski wrote: > This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X. > > All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*. > > On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options. > > As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test. > > Testing performed (with IP_DONTFRAGMENT flag): > Windows 10: > With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag. > Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable. > > For other systems I could not capture packets, so I can only report the observed behavior of sending packets. > Windows 2012 and 2016 (IP_MTU_DISCOVER not supported): > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds. > If a packet is sent to a non-routable address, send succeeds, no error is reported. > > Linux: > With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds. > > Mac OS X 12: > Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior. Thanks for taking care of this. One small comment. I think we should edit the comments (such as in src/java.base/unix/native/libnio/ch/Net.c, also the windows version) that say the dual set option call is only for multicast options to also include this option. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From michaelm at openjdk.org Mon Jul 25 10:55:06 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 25 Jul 2022 10:55:06 GMT Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header In-Reply-To: References: <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com> Message-ID: On Thu, 21 Jul 2022 17:41:22 GMT, Daniel Jeli?ski wrote: >> src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c line 207: >> >>> 205: } >>> 206: } >>> 207: return JNI_TRUE; >> >> Hello Daniel, if I'm reading this diff correctly, then we have inverted the check on `fd`. So I suspect this final `return` now needs to be changed to `return JNI_FALSE` to account for `fd` being `-1`? > > Hi Jaikiran, the point of this change was to better support systems where either IPv4 or IPv6 was disabled. I'm not sure if that can even happen on Mac. > The change here is that if we can't create one socket, we don't immediately return false, but instead return the result for the other socket. For example, if creating IPv4 socket fails, we only check if DF is supported on IPv6 socket, and return that as a result. If both `socket` calls fail, we don't know if the DF flag is supported, and return true (before the patch we would return false in that case). I can modify the patch to return false in that case, or roll back this change entirely if you think it makes no sense. I think this change makes sense so long as we are sure that if IPv4 or IPv6 is disabled then the right call happens for the other option. ------------- PR: https://git.openjdk.org/jdk/pull/9575 From bpb at openjdk.org Tue Jul 26 00:09:09 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 26 Jul 2022 00:09:09 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: References: Message-ID: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). 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 18 additional commits since the last revision: - 8057113: Revert return type back to a nullable-String; update test - Merge - 8057113: Remove extensions() test method; add threthree new test cases - 8057113: Revert excision of wild cards from imports - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() - Merge - 8057113: Change @since annotation to 20 - Merge - 8057113: Remove superfluous new Object[] statements from test - 8057113: Fix getExtension() commcents; improve hasExtension() implementation - ... and 8 more: https://git.openjdk.org/jdk/compare/53dfdb9d...23ca3f10 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/ec417a89..23ca3f10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=12-13 Stats: 135173 lines in 2720 files changed: 82774 ins; 33359 del; 19040 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From shade at openjdk.org Tue Jul 26 07:22:45 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Jul 2022 07:22:45 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Is @AlanBateman on vacation? Can I have someone review the NIO test change? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9554 From rpressler at openjdk.org Tue Jul 26 09:25:44 2022 From: rpressler at openjdk.org (Ron Pressler) Date: Tue, 26 Jul 2022 09:25:44 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <6rlQ25jHrT5G8ZrHqRarV1QF9rd9saZ82wCVKjVYQLU=.ffb206af-0100-4828-8966-fb74db4ccb98@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s He is. He'll be back next week, but maybe someone else wants to review this. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jpai at openjdk.org Tue Jul 26 10:10:05 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 10:10:05 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: > 34: * @test id=useDirectRegister > 35: * @bug 8284161 > 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? Other than that, this test change looks OK to me. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jpai at openjdk.org Tue Jul 26 10:18:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 10:18:49 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 10:06:31 GMT, Jaikiran Pai wrote: >> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. >> >> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: >> >> >> # release before >> real 4m41.424s >> user 24m18.064s >> sys 1m16.440s >> >> # release after >> real 2m47.769s ; -40% >> user 23m44.622s >> sys 1m15.240s >> >> >> # fastdebug before >> real 5m38.078s >> user 67m23.516s >> sys 1m56.446s >> >> # fastdebug after >> real 4m9.249s ; -26% >> user 67m21.940s >> sys 1m57.625s > > test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: > >> 34: * @test id=useDirectRegister >> 35: * @bug 8284161 >> 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels > > Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? > Other than that, this test change looks OK to me. On a related note - I had a brief look at the jtreg docs including the FAQ https://openjdk.org/jtreg/faq.html and I don't see any mention about how it treats multiple test definitions in a single source file, when it comes to running them concurrently. But I believe you have more experience with it and have already tested the difference in parallelism, so I think what you suggest here is fine. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From shade at openjdk.org Tue Jul 26 12:10:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Jul 2022 12:10:10 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 10:16:31 GMT, Jaikiran Pai wrote: >> test/jdk/java/nio/channels/vthread/BlockingChannelOps.java line 36: >> >>> 34: * @test id=useDirectRegister >>> 35: * @bug 8284161 >>> 36: * @summary Basic tests of virtual threads doing blocking I/O with NIO channels >> >> Hello Aleksey, I see that previously the `@bug` and `@summary` was only there on one test definition. So maybe remove this duplicated `@bug` and `@summary` from this new test definition? >> Other than that, this test change looks OK to me. > > On a related note - I had a brief look at the jtreg docs including the FAQ https://openjdk.org/jtreg/faq.html and I don't see any mention about how it treats multiple test definitions in a single source file, when it comes to running them concurrently. But I believe you have more experience with it and have already tested the difference in parallelism, so I think what you suggest here is fine. Yes, this is a usual thing to replicate the test sections. It is also a usual practice to copy-paste the entirety of run definition/config. ------------- PR: https://git.openjdk.org/jdk/pull/9554 From jpai at openjdk.org Tue Jul 26 13:00:38 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 26 Jul 2022 13:00:38 GMT Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply In-Reply-To: References: Message-ID: <6AktxwcOfu3Tg7aKa5d1fVa5aQJHqL7TrVzrmbJA4QU=.6977647f-a273-4da4-9926-88e4b916cc25@github.com> On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev wrote: > Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. > > Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`: > > > # release before > real 4m41.424s > user 24m18.064s > sys 1m16.440s > > # release after > real 2m47.769s ; -40% > user 23m44.622s > sys 1m15.240s > > > # fastdebug before > real 5m38.078s > user 67m23.516s > sys 1m56.446s > > # fastdebug after > real 4m9.249s ; -26% > user 67m21.940s > sys 1m57.625s Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9554 From aturbanov at openjdk.org Tue Jul 26 19:21:14 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 26 Jul 2022 19:21:14 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele wrote: > This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java. > > I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon. > > ### Testing > I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`: > > - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation. > - DeleteInterference.java fails for the same reason as above. > - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so. src/java.base/aix/classes/sun/nio/fs/AhafsPoller.java line 336: > 334: > 335: // If cancelling a TopLevelKey, also cancel any SubKeys > 336: if(wk instanceof AixWatchKey.TopLevelKey) { let's add space after `if` ------------- PR: https://git.openjdk.org/jdk/pull/9281 From bpb at openjdk.org Tue Jul 26 19:34:17 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 26 Jul 2022 19:34:17 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: On Tue, 26 Jul 2022 19:17:30 GMT, Andrey Turbanov wrote: >> This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java. >> >> I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon. >> >> ### Testing >> I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`: >> >> - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation. >> - DeleteInterference.java fails for the same reason as above. >> - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so. > > src/java.base/aix/classes/sun/nio/fs/AhafsPoller.java line 336: > >> 334: >> 335: // If cancelling a TopLevelKey, also cancel any SubKeys >> 336: if(wk instanceof AixWatchKey.TopLevelKey) { > > let's add space after `if` Yes, by convention no blank space before the left `(` is for functions / methods. ------------- PR: https://git.openjdk.org/jdk/pull/9281 From rriggs at openjdk.org Tue Jul 26 19:55:18 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 26 Jul 2022 19:55:18 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> References: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> Message-ID: On Tue, 26 Jul 2022 00:09:09 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > 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 18 additional commits since the last revision: > > - 8057113: Revert return type back to a nullable-String; update test > - Merge > - 8057113: Remove extensions() test method; add threthree new test cases > - 8057113: Revert excision of wild cards from imports > - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() > - Merge > - 8057113: Change @since annotation to 20 > - Merge > - 8057113: Remove superfluous new Object[] statements from test > - 8057113: Fix getExtension() commcents; improve hasExtension() implementation > - ... and 8 more: https://git.openjdk.org/jdk/compare/a08870fa...23ca3f10 Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/nio/file/Path.java line 102: > 100: * Otherwise stated, the internal representation might not be recoverable > 101: * from the derived path string. This applies to the {@code Path} as a whole > 102: * as well as to its components. This comment doesn't seem specific to the enhancement proposed. And its a bit vague, if/when included it might benefit from an example or mentioning the character set encoding of file names, if that's the context. src/java.base/share/classes/java/nio/file/Path.java line 305: > 303: } else if (length == 2 && > 304: !(fileNameString.charAt(0) == '.' || > 305: fileNameString.charAt(1) != '.')) { I would have coded it as: (length == 2 && fileNameString.charAt(0) != '.' && fileNameString.charat(1) == '.')) { As a better match for the comment. test/jdk/java/nio/file/Path/Extensions.java line 64: > 62: {".profile.sh", "sh"}, > 63: {"..foo", "foo"}, > 64: {".....foo", "foo"}, Duplicates the test of line 53. test/jdk/java/nio/file/Path/Extensions.java line 77: > 75: {"x.zip", "zip"}, > 76: {"y.gzip", "gzip"}, > 77: {"z.jar", "jar"}, Fewer test cases of a file with a 3 or 4 character extension would be fine too. Algorithm-wise they are all the same but may give a warm fuzzy that a favorite extension is covered. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Tue Jul 26 20:07:14 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 26 Jul 2022 20:07:14 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: References: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> Message-ID: On Tue, 26 Jul 2022 19:44:39 GMT, Roger Riggs wrote: >> 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 18 additional commits since the last revision: >> >> - 8057113: Revert return type back to a nullable-String; update test >> - Merge >> - 8057113: Remove extensions() test method; add threthree new test cases >> - 8057113: Revert excision of wild cards from imports >> - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() >> - Merge >> - 8057113: Change @since annotation to 20 >> - Merge >> - 8057113: Remove superfluous new Object[] statements from test >> - 8057113: Fix getExtension() commcents; improve hasExtension() implementation >> - ... and 8 more: https://git.openjdk.org/jdk/compare/74f81401...23ca3f10 > > src/java.base/share/classes/java/nio/file/Path.java line 305: > >> 303: } else if (length == 2 && >> 304: !(fileNameString.charAt(0) == '.' || >> 305: fileNameString.charAt(1) != '.')) { > > I would have coded it as: > > (length == 2 && > fileNameString.charAt(0) != '.' && > fileNameString.charat(1) == '.')) { > > As a better match for the comment. I had it that way originally but changed it thinking that fewer boolean expressions might need to be evaluated. > test/jdk/java/nio/file/Path/Extensions.java line 64: > >> 62: {".profile.sh", "sh"}, >> 63: {"..foo", "foo"}, >> 64: {".....foo", "foo"}, > > Duplicates the test of line 53. Check. > test/jdk/java/nio/file/Path/Extensions.java line 77: > >> 75: {"x.zip", "zip"}, >> 76: {"y.gzip", "gzip"}, >> 77: {"z.jar", "jar"}, > > Fewer test cases of a file with a 3 or 4 character extension would be fine too. > Algorithm-wise they are all the same but may give a warm fuzzy that a favorite extension is covered. Indeed that's all it is. I doubt more than one test of an n-character extension is necessary. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From aturbanov at openjdk.org Tue Jul 26 20:39:31 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 26 Jul 2022 20:39:31 GMT Subject: RFR: 8291061: Improve thread safety of FileTime.toString and toInstant Message-ID: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com> We need to read fields `instant`/`valueAsString` once, as to dodge/resolve the data race on reading lazily-initialized fields. ------------- Commit messages: - [PATCH] Improve thread safety of FileTime.toString and toInstant Changes: https://git.openjdk.org/jdk/pull/9608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291061 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9608.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9608/head:pull/9608 PR: https://git.openjdk.org/jdk/pull/9608 From bpb at openjdk.org Wed Jul 27 15:30:53 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 27 Jul 2022 15:30:53 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: References: Message-ID: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Correct length 2 case; update test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/23ca3f10..3f510ecc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=13-14 Stats: 35 lines in 2 files changed: 10 ins; 19 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Wed Jul 27 15:30:57 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 27 Jul 2022 15:30:57 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: References: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> Message-ID: On Tue, 26 Jul 2022 20:02:54 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 305: >> >>> 303: } else if (length == 2 && >>> 304: !(fileNameString.charAt(0) == '.' || >>> 305: fileNameString.charAt(1) != '.')) { >> >> I would have coded it as: >> >> (length == 2 && >> fileNameString.charAt(0) != '.' && >> fileNameString.charat(1) == '.')) { >> >> As a better match for the comment. > > I had it that way originally but changed it thinking that fewer boolean expressions might need to be evaluated. Changed in 3f510ecc32089589203b1fffb13eedc579aaa8bb. >> test/jdk/java/nio/file/Path/Extensions.java line 64: >> >>> 62: {".profile.sh", "sh"}, >>> 63: {"..foo", "foo"}, >>> 64: {".....foo", "foo"}, >> >> Duplicates the test of line 53. > > Check. Fixed in 3f510ecc32089589203b1fffb13eedc579aaa8bb. >> test/jdk/java/nio/file/Path/Extensions.java line 77: >> >>> 75: {"x.zip", "zip"}, >>> 76: {"y.gzip", "gzip"}, >>> 77: {"z.jar", "jar"}, >> >> Fewer test cases of a file with a 3 or 4 character extension would be fine too. >> Algorithm-wise they are all the same but may give a warm fuzzy that a favorite extension is covered. > > Indeed that's all it is. I doubt more than one test of an n-character extension is necessary. Fixed in 3f510ecc32089589203b1fffb13eedc579aaa8bb. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Wed Jul 27 15:32:30 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 27 Jul 2022 15:32:30 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> References: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> Message-ID: <8DLCAvzS1R8FP9Za5gFIdDJyz0OPc2WS9iq3-OATN-E=.a50abd57-e5ba-44f9-a4ad-181ab6fd78ce@github.com> On Tue, 26 Jul 2022 00:09:09 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > 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 18 additional commits since the last revision: > > - 8057113: Revert return type back to a nullable-String; update test > - Merge > - 8057113: Remove extensions() test method; add threthree new test cases > - 8057113: Revert excision of wild cards from imports > - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() > - Merge > - 8057113: Change @since annotation to 20 > - Merge > - 8057113: Remove superfluous new Object[] statements from test > - 8057113: Fix getExtension() commcents; improve hasExtension() implementation > - ... and 8 more: https://git.openjdk.org/jdk/compare/e7956ca7...23ca3f10 3f510ecc32089589203b1fffb13eedc579aaa8bb fixes the `..` case which was previously yielding `null` when it should be `""`. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From rriggs at openjdk.org Thu Jul 28 14:58:02 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 28 Jul 2022 14:58:02 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> References: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> Message-ID: On Wed, 27 Jul 2022 15:30:53 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Correct length 2 case; update test cases Looks good. As a default method, is there anything to say about when/if to implement for a specific file system. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From duke at openjdk.org Thu Jul 28 15:00:00 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 28 Jul 2022 15:00:00 GMT Subject: RFR: 8291061: Improve thread safety of FileTime.toString and toInstant In-Reply-To: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com> References: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com> Message-ID: On Fri, 22 Jul 2022 07:34:19 GMT, Andrey Turbanov wrote: > We need to read fields `instant`/`valueAsString` once, as to dodge/resolve the data race on reading lazily-initialized fields. Marked as reviewed by stsypanov at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.org/jdk/pull/9608 From bpb at openjdk.org Thu Jul 28 15:42:41 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 28 Jul 2022 15:42:41 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: References: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> Message-ID: <7wlwAb0GGzctn94JS79PiHNI-zSbotToCpag9kqdqrs=.1ebcc68f-b881-4762-a458-eecd95a457c7@github.com> On Thu, 28 Jul 2022 14:55:33 GMT, Roger Riggs wrote: > As a default method, is there anything to say about when/if to implement for a specific file system. I suppose it could say something like ```If an implementation maintains the Path in an internal representation which is not a String, then it might be best to override the default implementation to work with that representation until the result is obtained and only then convert the result to a String.``` ------------- PR: https://git.openjdk.org/jdk/pull/8066 From mr at openjdk.org Thu Jul 28 16:32:39 2022 From: mr at openjdk.org (Mark Reinhold) Date: Thu, 28 Jul 2022 16:32:39 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> References: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> Message-ID: On Wed, 27 Jul 2022 15:30:53 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Correct length 2 case; update test cases Changes requested by mr (Lead). src/java.base/share/classes/java/nio/file/Path.java line 264: > 262: * representation of the file name after the last dot ('.'). All leading > 263: * dots are ignored. If the extension is missing, then an > 264: * {@link String#isEmpty() empty} {@code String} ({@code ""}) is returned. Don?t you mean to say here that if the extension is missing then `null` is returned? That?s what the `@return` tag below implies, and that?s what would be most useful. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Thu Jul 28 16:43:43 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 28 Jul 2022 16:43:43 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: References: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> Message-ID: On Thu, 28 Jul 2022 16:29:02 GMT, Mark Reinhold wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8057113: Correct length 2 case; update test cases > > src/java.base/share/classes/java/nio/file/Path.java line 264: > >> 262: * representation of the file name after the last dot ('.'). All leading >> 263: * dots are ignored. If the extension is missing, then an >> 264: * {@link String#isEmpty() empty} {@code String} ({@code ""}) is returned. > > Don?t you mean to say here that if the extension is missing then `null` is returned? That?s what the `@return` tag below implies, and that?s what would be most useful. Yes, that is what it should be. This was translated incorrectly from the previous version returning `Optional`. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Thu Jul 28 18:15:00 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 28 Jul 2022 18:15:00 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v14] In-Reply-To: References: <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com> Message-ID: On Tue, 26 Jul 2022 19:28:38 GMT, Roger Riggs wrote: >> 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 18 additional commits since the last revision: >> >> - 8057113: Revert return type back to a nullable-String; update test >> - Merge >> - 8057113: Remove extensions() test method; add threthree new test cases >> - 8057113: Revert excision of wild cards from imports >> - 8057113: Add class level apiNote; improve getExtension() specification; remove hasExtension() and replaceExtension() >> - Merge >> - 8057113: Change @since annotation to 20 >> - Merge >> - 8057113: Remove superfluous new Object[] statements from test >> - 8057113: Fix getExtension() commcents; improve hasExtension() implementation >> - ... and 8 more: https://git.openjdk.org/jdk/compare/6f0aa05d...23ca3f10 > > src/java.base/share/classes/java/nio/file/Path.java line 102: > >> 100: * Otherwise stated, the internal representation might not be recoverable >> 101: * from the derived path string. This applies to the {@code Path} as a whole >> 102: * as well as to its components. > > This comment doesn't seem specific to the enhancement proposed. > And its a bit vague, if/when included it might benefit from an example or mentioning the character set encoding of file names, if that's the context. I am wondering now whether this note would just add unnecessary confusion. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From tsteele at openjdk.org Thu Jul 28 20:04:34 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 28 Jul 2022 20:04:34 GMT Subject: RFR: 8288627: [AIX] Implement WatchService using system library In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com> Message-ID: On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele wrote: > This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java. > > I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon. > > ### Testing > I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`: > > - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation. > - DeleteInterference.java fails for the same reason as above. > - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so. Thanks for the comments. I will be finishing up some work related to jdk19 over the next few weeks, and coming back to this as soon as I have a moment. This is still a priority for me. ------------- PR: https://git.openjdk.org/jdk/pull/9281 From bpb at openjdk.org Thu Jul 28 23:12:32 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 28 Jul 2022 23:12:32 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v16] In-Reply-To: References: Message-ID: > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Update specification, implementation, and test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/3f510ecc..8a4a4bc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=14-15 Stats: 25 lines in 2 files changed: 7 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Thu Jul 28 23:14:45 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 28 Jul 2022 23:14:45 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v15] In-Reply-To: References: <-r2h5j_YitCxvLbv1FkWULKLa6vWAojeE6dzGFD7GPg=.096b4675-955d-4768-9d82-f8bac10ebdef@github.com> Message-ID: <3fSSGmdlY-oMHQGc1VWonSqW2yBnrDNvlYvE44ywPd0=.29b417e2-bfb6-41e3-8f5e-04dfc827a83d@github.com> On Thu, 28 Jul 2022 16:41:27 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 264: >> >>> 262: * representation of the file name after the last dot ('.'). All leading >>> 263: * dots are ignored. If the extension is missing, then an >>> 264: * {@link String#isEmpty() empty} {@code String} ({@code ""}) is returned. >> >> Don?t you mean to say here that if the extension is missing then `null` is returned? That?s what the `@return` tag below implies, and that?s what would be most useful. > > Yes, that is what it should be. This was translated incorrectly from the previous version returning `Optional`. Fixed in 8a4a4bc6fc41453d9480a5eba0a8f227dd7ceadc. ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Fri Jul 29 16:05:15 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 29 Jul 2022 16:05:15 GMT Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for ":" at last index [v3] In-Reply-To: References: Message-ID: <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com> On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter wrote: >> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check >> >> int pos = syntaxAndInput.indexOf(':'); >> if (pos <= 0 || pos == syntaxAndInput.length()) >> >> to >> >> if (pos <= 0) > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8290047: Remove IAE message in JrtFileSystem.getPathMatcher() Is there anything else to be done in this PR? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9595 From mr at openjdk.org Fri Jul 29 17:30:58 2022 From: mr at openjdk.org (Mark Reinhold) Date: Fri, 29 Jul 2022 17:30:58 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v16] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 23:12:32 GMT, Brian Burkhalter wrote: >> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Update specification, implementation, and test Changes requested by mr (Lead). src/java.base/share/classes/java/nio/file/Path.java line 261: > 259: /** > 260: * Returns the file name extension of this path as a {@code String}. The > 261: * extension is defined to be the portion of the Omit "defined to be"; it's redundant. src/java.base/share/classes/java/nio/file/Path.java line 262: > 260: * Returns the file name extension of this path as a {@code String}. The > 261: * extension is defined to be the portion of the > 262: * {@link #getFileName file name} string after the last dot ('.'). All `{@linkplain #getFileName file name}` src/java.base/share/classes/java/nio/file/Path.java line 263: > 261: * extension is defined to be the portion of the > 262: * {@link #getFileName file name} string after the last dot ('.'). All > 263: * leading dots in the string are ignored. If the extension is missing, Simplify `All leading` to `Leading`. Change `the extension is missing` (which suggests an error) to `there is no extension`. src/java.base/share/classes/java/nio/file/Path.java line 268: > 266: * string does not contain a dot, or only the first character is a dot. > 267: * If the last character is a dot but some other character is not, then > 268: * the extension is the {@link String#isEmpty() empty} string. The term "dot" is imprecise. Consider saying `period character ('.', U+002E FULL STOP)` on first use (to be consistent with [other specifications][jlc]), and `period character` thereafter. [jlc]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/Character.html#isWhitespace(char) ------------- PR: https://git.openjdk.org/jdk/pull/8066 From bpb at openjdk.org Fri Jul 29 18:02:05 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 29 Jul 2022 18:02:05 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v17] In-Reply-To: References: Message-ID: <425zWn-fj1sCP-8G9UwgyCgFbkjOCNxk2Es5yP2OKHw=.fd8df49a-265a-43d8-9574-1bb9f55a6fa0@github.com> > Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319). Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Change specification as suggested in review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8066/files - new: https://git.openjdk.org/jdk/pull/8066/files/8a4a4bc6..d8df5141 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=15-16 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/8066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8066/head:pull/8066 PR: https://git.openjdk.org/jdk/pull/8066