From duke at openjdk.org Wed Jul 5 06:38:02 2023 From: duke at openjdk.org (Markus KARG) Date: Wed, 5 Jul 2023 06:38:02 GMT Subject: RFR: 8305744: (ch) InputStream returned by Channels.newInputStream should have fast path for ReadbleByteChannel/WritableByteChannel [v3] In-Reply-To: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> References: <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com> Message-ID: On Sun, 9 Apr 2023 13:43:36 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of ReadableByteChannel-to-WritableByteChannel transfers, where neither Channel is a FileChannel, but including special treatment of SelectableByteChannel. >> >> *Without* this optimization, the JRE applies a loop where a temporary 16k byte array on the Java heap is used to transport the data between both channels. This implies that data is first transported from the source channel into the Java heap and then from the Java heap to the target channel. For most Channels, as these are NIO citizen, this implies two transfers between Java heap and OS resources, which is rather time consuming. As the data is in no way modified by transferTo(), the temporary allocation of valuable heap memory is just as unnecessary as both transfers to and from the heap. It makes sense to prevent the use of Java heap memory. >> >> This optimization omits the byte array on the Java heap, effectively omitting the transfers to and from that array in turn. Instead, the transfer happens directly from Channel to Channel reusing a ByteBuffer taken from the JRE's internal buffer management utility which also has a size of 16k. Both measures make the transfer more efficient, as just the very essential resources are used, but not more. >> >> Using JMH on an in-memory data transfer using custom Channels (to prevent interception by other optimizations already existing in transferTo()) it was possible to measure a 2,5% performance gain. While this does not sound much, just as the spared 16k of Java heap doesn't, we need to consider that this also means sparing GC pressure, power consumption and CO2 footprint, and we need to consider that it could be higher when using different (possibly third-party) kinds of custom Channels (as "real I/O" between heap and OS-resources is way slower than the RAM-to-RAM benchmark applied by me). As the change does not induce new, extraordinary risks compared to the existing source code, I think it is worth gaining that 2,5+ percent. Possibly there might exist some kind of scalable Java-implemented cloud service that is bound to exactly this loop and that transports very heavy traffic, those particular 2,5+ percent could be a huge amount of kWh or CO2 in absolute numbers. Even if not now, t here might be in future. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Putting the special casing for an output stream backed by a ChannelOutputStream in one place. # TL;DR This MR outperforms the master branch's code by one order of magnitude in the best case, but is never slower in the worst case. # Proof To proof this claim, Brian's benchmark is used with two different edge cases. ## Lower Bound: ByteArray-Streams Using Brian's code (see above) I could proof that this MR is always at-least-as fast as the original code. ByteArray-Streams using code from this MR: Result "eu.sandbox.Sandbox.ChannelInputStream_transferTo": 2.727 ?(99.9%) 0.096 ops/s [Average] (min, avg, max) = (2.526, 2.727, 2.900), stdev = 0.128 CI (99.9%): [2.631, 2.823] (assumes normal distribution) ByteArray-Streams using original code from master branch: Result "eu.sandbox.Sandbox.ChannelInputStream_transferTo": 2.725 ?(99.9%) 0.103 ops/s [Average] (min, avg, max) = (2.551, 2.725, 2.935), stdev = 0.138 CI (99.9%): [2.622, 2.828] (assumes normal distribution) The reason that no statistical evidence for *improved* performance could be found *in this edge case* is clearly bound to the fact that what we measure here mostly is the time needed by the ByteArray*Streams to transfer bytes between the byte arrays. This needs *very* long time - *much* more time than the actual code change that we actually wanted to benchmark. Copying Gigabytes between the byte arrays is *not* the target of this MR's optimization, but happens in exact the same way in the original code just as in the MR's code, and is (more or less) *solely* what Brian's bechnmark is actually measuring. Hence it is clear, that the statistical result reflects just the fact that copying Gigabytes costs a lot of time, but says rather nothing about the *actual* optimization this MR is about. ## Upper Bound: No-Op-Channels In fact, what this MR optimizes is not Channel-wrapped ByteArray*Streams (even if Brian's benchmark has proven that they will not work any slower than before), but is -as I explained earlier- custom channels. As `Channel` is a public interface since very long time (starting with Java 1.4), it is possible and likely that custom implementations *do* exist in field use. There could be, for example, channels that use native memory *solely*, even there could be channels that do not transfer the data at all but simple forward buffers from reable channel to writable channel in a hardware-supported way. We do not know what those optimized custom channels actually work like, but as this optimization is about the proof that channel-to-channel transfer is (way) faster than channel-to-bytearray-to-channel transfer (as the original code works like), we actually do not care about the actual implementation of the custom channels. Moreover, we do not care about that, because both benchmark runs (the master code just as the MR's code) will read and write the channels in full length using the same public interface methods, so it is irrelevant what these methods actually do (as long as they do it correctly). Basing on this theory, I have modified Brian's code to not further use byte arrays in those channels, but to use No-Op-Channels. This means, channels that behave *correctly* (i. e. their interface methods work consistently with the spec, and the input channel provides the full length of bytes) but whose implementations do not *copy* any bytes. Using this variation of the benchmark, we now have the means to measure what we actually wanted to measure in the first place: How much faster is the MR's code compared to master's code? Hence: We do not measure anymore how much time the particular *implementation* of an arbitraritly chosen Input/OutputStream needs - again, as this is the same time for all tests as this code is *unchanged*. Using No-Op-Channels I could proof that the actual modification is highly beneficial, as the MR's code clearly outperforms master's code by one full order of magnitude: No-Op-Channel-Streams using code from this MR: Result "eu.sandbox.Sandbox.ChannelInputStream_transferTo": 3403.370 ?(99.9%) 287.694 ops/s [Average] (min, avg, max) = (1977.793, 3403.370, 3759.044), stdev = 384.063 CI (99.9%): [3115.676, 3691.063] (assumes normal distribution) No-Op-Channel-Streams using code from master: Result "eu.sandbox.Sandbox.ChannelInputStream_transferTo": 349.644 ?(99.9%) 27.853 ops/s [Average] (min, avg, max) = (240.305, 349.644, 366.043), stdev = 37.182 CI (99.9%): [321.792, 377.497] (assumes normal distribution) I assume that the statistical evidence is obvious, just as the reasoning is: Not having to move one Gigabyte of data from a ByteBuffer into a byte array and back once per test iteration certainly is (much) faster than doing it. While CPUs and memory paths are super fast these days, the transfer costs still are *not zero*, and one Gigabyte transferred twice per test makes this rather evident. That free CPU, MMU and transfer path resources (and the time needed for the spared GCs) can be used better for parallel tasks (or spared completely to spare CO2). Below you can find the implementation of the Null-Op-Channels: private static NullReadableByteChannel newNullReadableByteChannel(final int size) { return new NullReadableByteChannel(size); } private static class NullReadableByteChannel implements ReadableByteChannel { private NullReadableByteChannel(final int size) { this.size = size; s = size; } int s, size; private boolean isClosed; @Override public boolean isOpen() { return !isClosed; } @Override public void close() throws IOException { this.isClosed = true; } @Override public int read(ByteBuffer dst) throws IOException { if (isClosed) throw new ClosedChannelException(); if (s <= 0) return -1; final int p = dst.position(); final int r = dst.remaining(); final int c = Math.min(r, s); dst.position(p + c); s -= c; return c; } public void reset() { s = size; } } private static WritableByteChannel newNullWritableByteChannel() { return new WritableByteChannel() { private boolean isClosed; @Override public boolean isOpen() { return !isClosed; } @Override public void close() throws IOException { this.isClosed = true; } @Override public int write(ByteBuffer src) throws IOException { if (isClosed) throw new ClosedChannelException(); final int p = src.position(); final int r = src.remaining(); final int c = r; src.position(p + c); return c; } }; } ------------- PR Comment: https://git.openjdk.org/jdk/pull/13387#issuecomment-1621114554 From lancea at openjdk.org Wed Jul 5 16:53:53 2023 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 5 Jul 2023 16:53:53 GMT Subject: RFR: 8311183: Remove unused mapping test files In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato wrote: > There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed. Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14757#pullrequestreview-1514950023 From bpb at openjdk.org Wed Jul 5 17:08:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 5 Jul 2023 17:08:56 GMT Subject: RFR: 8311183: Remove unused mapping test files In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato wrote: > There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed. +1 ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14757#pullrequestreview-1514980588 From naoto at openjdk.org Wed Jul 5 23:31:04 2023 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 5 Jul 2023 23:31:04 GMT Subject: Integrated: 8311183: Remove unused mapping test files In-Reply-To: References: Message-ID: <7t1XdHgfOIvk0W4hzJ-0ppHjR2W2DKUwKSK-3P7E3Yw=.32776839-6368-4556-9ee0-60a14d31e458@github.com> On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato wrote: > There are unused charset mapping test files under `test/jdk/sun/nio/cs/mapping` directory, where one of them (`JIS0212.b2c.private`) has a questionable copyright header from the Unicode Consortium. They should be removed. This pull request has now been integrated. Changeset: d072c40f Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/d072c40ff175c653802796673baef47e24038891 Stats: 40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod 8311183: Remove unused mapping test files Reviewed-by: lancea, bpb ------------- PR: https://git.openjdk.org/jdk/pull/14757 From lancea at openjdk.org Thu Jul 6 18:10:53 2023 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 6 Jul 2023 18:10:53 GMT Subject: [jdk21] RFR: 8311183: Remove unused mapping test files In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato wrote: > Hi all, > > This pull request contains a backport of commit [d072c40f](https://github.com/openjdk/jdk/commit/d072c40ff175c653802796673baef47e24038891) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 5 Jul 2023 and was reviewed by Lance Andersen and Brian Burkhalter. > > Thanks! Marked as reviewed by lancea (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/98#pullrequestreview-1517069942 From naoto at openjdk.org Fri Jul 7 15:50:57 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 7 Jul 2023 15:50:57 GMT Subject: [jdk21] Integrated: 8311183: Remove unused mapping test files In-Reply-To: References: Message-ID: On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato wrote: > Hi all, > > This pull request contains a backport of commit [d072c40f](https://github.com/openjdk/jdk/commit/d072c40ff175c653802796673baef47e24038891) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 5 Jul 2023 and was reviewed by Lance Andersen and Brian Burkhalter. > > Thanks! This pull request has now been integrated. Changeset: 773bb0a7 Author: Naoto Sato URL: https://git.openjdk.org/jdk21/commit/773bb0a7f110bd58359498334d7084eaca897e3a Stats: 40027 lines in 6 files changed: 0 ins; 40027 del; 0 mod 8311183: Remove unused mapping test files Reviewed-by: lancea Backport-of: d072c40ff175c653802796673baef47e24038891 ------------- PR: https://git.openjdk.org/jdk21/pull/98 From bpb at openjdk.org Fri Jul 7 18:58:06 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 7 Jul 2023 18:58:06 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string Message-ID: Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. ------------- Commit messages: - 8262742: (fs) Add Path::resolve with varargs string Changes: https://git.openjdk.org/jdk/pull/14805/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8262742 Stats: 219 lines in 3 files changed: 218 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Fri Jul 7 18:58:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 7 Jul 2023 18:58:07 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Default methods are added to the `Path` interface and a Unix version is added for the principal `resolve` method using `Path` parameters. The Unix implementation is about 20% faster than the default implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14805#issuecomment-1625893207 From jpai at openjdk.org Sat Jul 8 06:03:11 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jul 2023 06:03:11 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. src/java.base/share/classes/java/nio/file/Path.java line 524: > 522: *

The result of this method is the same as would be obtained > 523: * by resolving the first parameter path against this path, then > 524: * resovling the second parameter path against the derived path, Typo - should have been "resolving" instead of "resovling" src/java.base/share/classes/java/nio/file/Path.java line 545: > 543: * > 544: * @throws InvalidPathException > 545: * if the path string cannot be converted to a Path. Is this `@throws InvalidPathException` applicable for this method, since this doesn't take any string arguments? src/java.base/share/classes/java/nio/file/Path.java line 553: > 551: default Path resolve(Path first, Path... more) { > 552: Path result = resolve(first); > 553: for (Path p : more) { Hello Brian, do you think there should be a `@throws NullPointerException` in the javadoc, if any of these `Path` values is `null`? src/java.base/share/classes/java/nio/file/Path.java line 567: > 565: *

The result of this method is the same as would be obtained > 566: * by resolving the first parameter path string against this path, then > 567: * resovling the second parameter path string against the derived path, Typo - should have been "resolving" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257061885 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257063435 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257060227 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257064549 From duke at openjdk.org Sat Jul 8 10:38:04 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 8 Jul 2023 10:38:04 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com> On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. src/java.base/share/classes/java/nio/file/Path.java line 551: > 549: * @since 22 > 550: */ > 551: default Path resolve(Path first, Path... more) { It?might be?better to?have a?`(Path...)Path`?overload, so?that when?you?have an?array of?`Path`s or?`String`s, you?don?t?have to?manually?extract the?first?element and?copy the?array?using: path.resolve(paths[0], Arrays.copyOfRange(paths, 1, paths.length)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257219478 From jpai at openjdk.org Sat Jul 8 12:52:56 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 8 Jul 2023 12:52:56 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com> References: <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com> Message-ID: On Sat, 8 Jul 2023 10:34:44 GMT, ExE Boss wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > src/java.base/share/classes/java/nio/file/Path.java line 551: > >> 549: * @since 22 >> 550: */ >> 551: default Path resolve(Path first, Path... more) { > > It?might be?better to?have a?`(Path...)Path`?overload, so?that when?you?have an?array of?`Path`s or?`String`s, you?don?t?have to?manually?extract the?first?element and?copy the?array?using: > > path.resolve(paths[0], Arrays.copyOfRange(paths, 1, paths.length)) Hello @ExE-Boss > It might be better to have a (Path...)Path Do you mean introducing: default Path resolve(Path... more) { ... } If so, then it would allow calls like: Path p = ... p.resolve(); (i.e. calling resolve without any parameter) I think that would be odd and wrong for the API to allow that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257260603 From alanb at openjdk.org Mon Jul 10 06:17:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Jul 2023 06:17:55 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 05:55:08 GMT, Jaikiran Pai wrote: > Hello Brian, do you think there should be a `@throws NullPointerException` in the javadoc, if any of these `Path` values is `null`? There is a paragraph in the package description to cover this, it avoids cluttering the methods with "@throws NPE". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257755316 From jpai at openjdk.org Mon Jul 10 06:22:54 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 10 Jul 2023 06:22:54 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: On Mon, 10 Jul 2023 06:15:29 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 553: >> >>> 551: default Path resolve(Path first, Path... more) { >>> 552: Path result = resolve(first); >>> 553: for (Path p : more) { >> >> Hello Brian, do you think there should be a `@throws NullPointerException` in the javadoc, if any of these `Path` values is `null`? > >> Hello Brian, do you think there should be a `@throws NullPointerException` in the javadoc, if any of these `Path` values is `null`? > > There is a paragraph in the package description to cover this, it avoids cluttering the methods with "@throws NPE". You're right indeed. The `package-info.java` does say: Unless otherwise noted, passing a {@code null} argument to a * constructor or method in any class or interface in this package * will cause a {@link java.lang.NullPointerException * NullPointerException} to be thrown. Before commenting, I had checked if the class level documentation had this detail and didn't see it, but I had forgotten to check package level documentation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1257759329 From bpb at openjdk.org Mon Jul 10 16:20:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 10 Jul 2023 16:20:25 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: Message-ID: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: - 8262742: Fix typo - 8262742: Remove invalid "throws InvalidPathException"; correct typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/2f40ba8b..dd8c1413 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Mon Jul 10 16:20:30 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 10 Jul 2023 16:20:30 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: Message-ID: On Sat, 8 Jul 2023 05:56:40 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8262742: Fix typo >> - 8262742: Remove invalid "throws InvalidPathException"; correct typo > > src/java.base/share/classes/java/nio/file/Path.java line 524: > >> 522: *

The result of this method is the same as would be obtained >> 523: * by resolving the first parameter path against this path, then >> 524: * resovling the second parameter path against the derived path, > > Typo - should have been "resolving" instead of "resovling" Fixed in dd8c1413fc42b6b526d77c7131a10969353e0d08. > src/java.base/share/classes/java/nio/file/Path.java line 545: > >> 543: * >> 544: * @throws InvalidPathException >> 545: * if the path string cannot be converted to a Path. > > Is this `@throws InvalidPathException` applicable for this method, since this doesn't take any string arguments? You are correct: that is inapplicable. Fixed in b55ade04905de70264a682404996f2f982964b01. > src/java.base/share/classes/java/nio/file/Path.java line 567: > >> 565: *

The result of this method is the same as would be obtained >> 566: * by resolving the first parameter path string against this path, then >> 567: * resovling the second parameter path string against the derived path, > > Typo - should have been "resolving" Fix in b55ade04905de70264a682404996f2f982964b01. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1258492048 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1258488611 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1258488881 From bpb at openjdk.org Mon Jul 10 16:20:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 10 Jul 2023 16:20:31 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com> Message-ID: <6b5OjBVBrS79n5MEfYB4c1W6htuBqkhmu7eqOggmTdk=.d117ffc1-0ba7-4274-ac23-3157e72d0cca@github.com> On Sat, 8 Jul 2023 12:49:51 GMT, Jaikiran Pai wrote: > I think that would be odd and wrong for the API to allow that. Agreed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1258490204 From naoto at openjdk.org Tue Jul 11 16:14:24 2023 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 11 Jul 2023 16:14:24 GMT Subject: Integrated: 8310047: Add UTF-32 based Charsets into StandardCharsets In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 17:24:19 GMT, Naoto Sato wrote: > To make UTF-32 consistent with other UTF Charsets, making them available as `StandardCharsets`. A CSR has also been drafted. This pull request has now been integrated. Changeset: 00c7f914 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/00c7f914c665a77842d32eb8f760dcbbbda66554 Stats: 60 lines in 4 files changed: 50 ins; 0 del; 10 mod 8310047: Add UTF-32 based Charsets into StandardCharsets Reviewed-by: alanb, lancea, bpb, jpai, jlu ------------- PR: https://git.openjdk.org/jdk/pull/14599 From jlu at openjdk.org Tue Jul 11 17:14:25 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 11 Jul 2023 17:14:25 GMT Subject: RFR: 8310683: Refactor StandardCharset/standard.java to use JUnit [v6] In-Reply-To: References: Message-ID: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge master - Just use charsetFields() - Review: reuse the standard charset fields - Merge branch 'pr/14599' of https://git.openjdk.org/jdk into JUnit-StandardCharsets - Merge branch 'master' into JDK-8310047-UTF-32 - Merge pr/14599 - Update test/jdk/java/nio/charset/StandardCharsets/Standard.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - 8310047: Add UTF-32 based Charsets into StandardCharsets - Additional cleanup - Refactor Standard.java to use JUnit + other cleanup - ... and 1 more: https://git.openjdk.org/jdk/compare/401c3dea...71ab598a ------------- Changes: https://git.openjdk.org/jdk/pull/14621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14621&range=05 Stats: 129 lines in 1 file changed: 42 ins; 28 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/14621.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14621/head:pull/14621 PR: https://git.openjdk.org/jdk/pull/14621 From jlu at openjdk.org Tue Jul 11 20:46:21 2023 From: jlu at openjdk.org (Justin Lu) Date: Tue, 11 Jul 2023 20:46:21 GMT Subject: Integrated: 8310683: Refactor StandardCharset/standard.java to use JUnit In-Reply-To: References: Message-ID: On Thu, 22 Jun 2023 23:56:46 GMT, Justin Lu wrote: > Please review this PR which is apart of the migration of JDK tests to JUnit. Standard.java is refactored to use JUnit, and thus split up into the following tests. > > - typeTest > - nameMethodTest > - forNameMethodTest > - charsetModifiersTest > - correctCharsetsTest > > Additionally all unused methods were removed. This pull request has now been integrated. Changeset: d82ade35 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/d82ade354570a930d8282684a8ffd368c613defc Stats: 129 lines in 1 file changed: 42 ins; 28 del; 59 mod 8310683: Refactor StandardCharset/standard.java to use JUnit Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/14621 From rriggs at openjdk.org Tue Jul 11 21:18:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Jul 2023 21:18:13 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> References: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> Message-ID: On Mon, 10 Jul 2023 16:20:25 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: > > - 8262742: Fix typo > - 8262742: Remove invalid "throws InvalidPathException"; correct typo src/java.base/share/classes/java/nio/file/Path.java line 520: > 518: > 519: /** > 520: * Resolves a path or a sequence of paths against this path. "or" -> "and then" src/java.base/share/classes/java/nio/file/Path.java line 574: > 572: * Path result = resolve(first); > 573: * for (String s : more) { > 574: * result = result.resolve(s); The code here doesn't match the description, converts to Paths and then resolves. Though it might not be detectable. src/java.base/share/classes/java/nio/file/Path.java line 586: > 584: * @throws InvalidPathException > 585: * if the path string cannot be converted to a Path. > 586: * When an InvalidPathException is thrown, what information is available to identify the illegal string? "if the path" -> "if a path" or "if any of the paths". test/jdk/java/nio/file/Path/PathOps.java line 1728: > 1726: .resolve("/foo", "", "foo") > 1727: .resolve("/bar", "foo", "", "/bar"); > 1728: Should there be test cases that include multiple directories in a path: "abc/def/xyz"? Also cases with "..", or is that only relevant if canonicalizing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260285130 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260285994 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260282403 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260290443 From bpb at openjdk.org Wed Jul 12 00:53:18 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 12 Jul 2023 00:53:18 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> Message-ID: On Tue, 11 Jul 2023 21:09:15 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8262742: Fix typo >> - 8262742: Remove invalid "throws InvalidPathException"; correct typo > > src/java.base/share/classes/java/nio/file/Path.java line 520: > >> 518: >> 519: /** >> 520: * Resolves a path or a sequence of paths against this path. > > "or" -> "and then" Like in `Path.of`, the first parameter may be considered element zero of the sequence which was the intent here. > src/java.base/share/classes/java/nio/file/Path.java line 574: > >> 572: * Path result = resolve(first); >> 573: * for (String s : more) { >> 574: * result = result.resolve(s); > > The code here doesn't match the description, converts to Paths and then resolves. > Though it might not be detectable. Description updated in 1b0c5228e05cc4a685f18b949be99f73f5e1b208. > src/java.base/share/classes/java/nio/file/Path.java line 586: > >> 584: * @throws InvalidPathException >> 585: * if the path string cannot be converted to a Path. >> 586: * > > When an InvalidPathException is thrown, what information is available to identify the illegal string? > > "if the path" -> "if a path" or "if any of the paths". The message of `InvalidPathException` is most often created in `UnixPath`, `WindowsPath`, and `WindowsPathParser` and indicates the problem, e.g., `nul` character, unmappable character, etc. Exception doc updated in 1b0c5228e05cc4a685f18b949be99f73f5e1b208. > test/jdk/java/nio/file/Path/PathOps.java line 1728: > >> 1726: .resolve("/foo", "", "foo") >> 1727: .resolve("/bar", "foo", "", "/bar"); >> 1728: > > Should there be test cases that include multiple directories in a path: "abc/def/xyz"? > Also cases with "..", or is that only relevant if canonicalizing. Multiple directories would be good but I don't know about `..`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260431320 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260431419 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260430902 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1260431676 From bpb at openjdk.org Wed Jul 12 00:53:14 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 12 Jul 2023 00:53:14 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v3] In-Reply-To: References: Message-ID: <6w3i-y5a7qaMhcZ87DNXsd9w2gESNT-iFCvKRDeKCnc=.7cf8bef1-1eb1-4db8-84f4-f34ff283233d@github.com> > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Verbiage cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/dd8c1413..1b0c5228 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=01-02 Stats: 16 lines in 1 file changed: 0 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From alanb at openjdk.org Wed Jul 12 11:35:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 12 Jul 2023 11:35:10 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v3] In-Reply-To: <6w3i-y5a7qaMhcZ87DNXsd9w2gESNT-iFCvKRDeKCnc=.7cf8bef1-1eb1-4db8-84f4-f34ff283233d@github.com> References: <6w3i-y5a7qaMhcZ87DNXsd9w2gESNT-iFCvKRDeKCnc=.7cf8bef1-1eb1-4db8-84f4-f34ff283233d@github.com> Message-ID: <7YV4eHMOo9CNIIvXAzKh4qaJU7iNx-l9I3Lo1DUJgnY=.5e7ece74-2bf2-445d-a5fc-c63e026b1cd3@github.com> On Wed, 12 Jul 2023 00:53:14 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Verbiage cleanup src/java.base/share/classes/java/nio/file/Path.java line 520: > 518: > 519: /** > 520: * Resolves a path, or a sequence of paths against this path. I think we'll need to come up with a better first line because the method doesn't resolve the sequence of paths against this path, it instead resolves the first path against this path, then iteratively resolves. I think the second paragraph will need to include something about empty elements, as we have in the existing resolve spec. src/java.base/share/classes/java/nio/file/Path.java line 539: > 537: * @param first the first path to resolve against this path > 538: * > 539: * @param more additional paths to be joined to form the path "additional paths to be joined to form the path" may be copied from elsewhere :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1261043373 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1261043761 From duke at openjdk.org Wed Jul 12 12:55:34 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 12:55:34 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base Message-ID: Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. ------------- Commit messages: - Update DateTimeFormatterBuilder - Avoid locale-sensitive case conversions in java.base Changes: https://git.openjdk.org/jdk/pull/14763/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8311943 Stats: 51 lines in 13 files changed: 9 ins; 0 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/14763.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14763/head:pull/14763 PR: https://git.openjdk.org/jdk/pull/14763 From jpai at openjdk.org Wed Jul 12 12:55:34 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 12 Jul 2023 12:55:34 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:53:34 GMT, Glavo wrote: > Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. Hello Glavo, I've created https://bugs.openjdk.org/browse/JDK-8311943 to track this change. Please update the title to this PR to `8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base` so that it triggers the official RFR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14763#issuecomment-1632426553 From alanb at openjdk.org Wed Jul 12 13:29:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 12 Jul 2023 13:29:11 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:53:34 GMT, Glavo wrote: > Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. src/java.base/share/classes/java/io/StreamTokenizer.java line 632: > 630: sval = String.copyValueOf(buf, 0, i); > 631: if (forceLower) > 632: sval = sval.toLowerCase(Locale.ROOT); I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261178834 From duke at openjdk.org Wed Jul 12 14:35:16 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 14:35:16 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 13:26:03 GMT, Alan Bateman wrote: > I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. I investigated some usage of this method on GitHub: https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code In the use cases I see, it seems that no one wants to rely on the default locale. However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261271535 From duke at openjdk.org Wed Jul 12 15:06:36 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 15:06:36 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: <8j9x5j5Gw_A5Oz1yKloOUaYOIOCUqGxIT_7U9UsnQDE=.7591e55d-c111-4c43-b82a-5f0252019b62@github.com> > Clean up misuses of `toLowerCase()`/`toUpperCase()` in java.base. Glavo has updated the pull request incrementally with one additional commit since the last revision: Revert StreamTokenizer.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14763/files - new: https://git.openjdk.org/jdk/pull/14763/files/944acdc4..8b8957f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14763&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14763.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14763/head:pull/14763 PR: https://git.openjdk.org/jdk/pull/14763 From uschindler at openjdk.org Wed Jul 12 16:08:17 2023 From: uschindler at openjdk.org (Uwe Schindler) Date: Wed, 12 Jul 2023 16:08:17 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 14:31:53 GMT, Glavo wrote: >> src/java.base/share/classes/java/io/StreamTokenizer.java line 632: >> >>> 630: sval = String.copyValueOf(buf, 0, i); >>> 631: if (forceLower) >>> 632: sval = sval.toLowerCase(Locale.ROOT); >> >> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. > >> I suspect this change to StreamTokenizer needs eyes. I think long standing behavior of the lowerCaseMode(true) has been to use the rules for the default locale so we need to be careful. > > I investigated usage of this method on GitHub: > > https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code > > In some of the use cases I investigated, it seems that no one wants to rely on the default locale. > > However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again. This is just a suggestion to be explicit as it makes maintaining the code easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261404900 From duke at openjdk.org Wed Jul 12 16:22:15 2023 From: duke at openjdk.org (Glavo) Date: Wed, 12 Jul 2023 16:22:15 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 16:05:03 GMT, Uwe Schindler wrote: > Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again. > > This is just a suggestion to be explicit as it makes maintaining the code easier. I agree with this. I'm working on deprecating `toLowerCase()` and `toUpperCase()`, this PR is part of that effort. I wish to convert all use cases of them to `toLowerCase(Locale)` and `toUpperCase(Locale)`. More backstory is detailed in https://github.com/openjdk/jdk/pull/13434#issuecomment-1503989660. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261421937 From bpb at openjdk.org Wed Jul 12 17:09:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 12 Jul 2023 17:09:25 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v4] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Attempt to improve specifications of varargs resolve methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/1b0c5228..09704e08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=02-03 Stats: 25 lines in 1 file changed: 19 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Wed Jul 12 17:12:09 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 12 Jul 2023 17:12:09 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v3] In-Reply-To: <7YV4eHMOo9CNIIvXAzKh4qaJU7iNx-l9I3Lo1DUJgnY=.5e7ece74-2bf2-445d-a5fc-c63e026b1cd3@github.com> References: <6w3i-y5a7qaMhcZ87DNXsd9w2gESNT-iFCvKRDeKCnc=.7cf8bef1-1eb1-4db8-84f4-f34ff283233d@github.com> <7YV4eHMOo9CNIIvXAzKh4qaJU7iNx-l9I3Lo1DUJgnY=.5e7ece74-2bf2-445d-a5fc-c63e026b1cd3@github.com> Message-ID: On Wed, 12 Jul 2023 11:30:41 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262742: Verbiage cleanup > > src/java.base/share/classes/java/nio/file/Path.java line 520: > >> 518: >> 519: /** >> 520: * Resolves a path, or a sequence of paths against this path. > > I think we'll need to come up with a better first line because the method doesn't resolve the sequence of paths against this path, it instead resolves the first path against this path, then iteratively resolves. > > I think the second paragraph will need to include something about empty elements, as we have in the existing resolve spec. Heavily reworked in 09704e08d6e1ba6c53bf8a7280a044c1a51e812d. > src/java.base/share/classes/java/nio/file/Path.java line 539: > >> 537: * @param first the first path to resolve against this path >> 538: * >> 539: * @param more additional paths to be joined to form the path > > "additional paths to be joined to form the path" may be copied from elsewhere :-) Blindly, even. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1261474932 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1261473838 From mbaesken at openjdk.org Thu Jul 13 09:27:29 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 09:27:29 GMT Subject: RFR: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX Message-ID: We run into this build warning on AIX : /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] #elif __linux__ 1 warning generated. Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. ------------- Commit messages: - JDK-8312013 Changes: https://git.openjdk.org/jdk/pull/14864/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14864&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312013 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14864/head:pull/14864 PR: https://git.openjdk.org/jdk/pull/14864 From alanb at openjdk.org Thu Jul 13 10:03:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 13 Jul 2023 10:03:55 GMT Subject: RFR: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken wrote: > We run into this build warning on AIX : > /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] > #elif __linux__ > 1 warning generated. > > Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. Looks okay, must have slipped in at some point. Can you update the date on copyright header before integrating? ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14864#pullrequestreview-1528079372 From vtewari at openjdk.org Thu Jul 13 11:10:00 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Thu, 13 Jul 2023 11:10:00 GMT Subject: RFR: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken wrote: > We run into this build warning on AIX : > /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] > #elif __linux__ > 1 warning generated. > > Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/14864#pullrequestreview-1528186346 From mbaesken at openjdk.org Thu Jul 13 13:55:23 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 13:55:23 GMT Subject: RFR: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX [v2] In-Reply-To: References: Message-ID: > We run into this build warning on AIX : > /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] > #elif __linux__ > 1 warning generated. > > Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: adjust COPYRIGHT headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14864/files - new: https://git.openjdk.org/jdk/pull/14864/files/e53bf994..894c6bcb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14864&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14864&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14864.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14864/head:pull/14864 PR: https://git.openjdk.org/jdk/pull/14864 From mbaesken at openjdk.org Thu Jul 13 14:06:14 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 14:06:14 GMT Subject: Integrated: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken wrote: > We run into this build warning on AIX : > /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] > #elif __linux__ > 1 warning generated. > > Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. This pull request has now been integrated. Changeset: b587fc51 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b587fc51a8bde2794f929b43af79fa7be00c9081 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX Reviewed-by: alanb, vtewari ------------- PR: https://git.openjdk.org/jdk/pull/14864 From mbaesken at openjdk.org Thu Jul 13 14:06:13 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Jul 2023 14:06:13 GMT Subject: RFR: JDK-8312013: avoid UnixConstants.java.template warning: '__linux__' is not defined on AIX [v2] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 13:55:23 GMT, Matthias Baesken wrote: >> We run into this build warning on AIX : >> /jdk/src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template:127:7: warning: '__linux__' is not defined, evaluates to 0 [-Wundef] >> #elif __linux__ >> 1 warning generated. >> >> Looks like the preprocessor check should be adjusted, because the macro is not present on non-Linux systems. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > adjust COPYRIGHT headers Hi Alan and Vyom, thanks for the reviews . I adjusted the COPYRIGHT header. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14864#issuecomment-1634302195 From duke at openjdk.org Thu Jul 13 15:18:25 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter wrote: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. src/java.base/share/classes/java/nio/X-Buffer.java.template line 1463: > 1461: * that is, if > 1462: * end - start {@code >}  > 1463: * {@code limit()} - {@code index}, Suggestion: * end - start > limit() - index, src/java.base/share/classes/java/nio/X-Buffer.java.template line 1490: > 1488: *

    > 1489: *
  • defines the range of characters to be read from the source in terms > 1490: * of the half-open interval {@code [start,} {@code end)} instead of Suggestion: * of the half-open interval [start, end) instead of src/java.base/share/classes/java/nio/X-Buffer.java.template line 1495: > 1493: * {@code IndexOutOfBoundsException} for the condition > 1494: * {@code index} {@code +} {@code end} {@code -}  > 1495: * {@code start} {@code >} {@code limit()}.
  • Suggestion: * index + end - start > limit(). src/java.base/share/classes/java/nio/X-Buffer.java.template line 1529: > 1527: * @see #append(CharSequence,int,int) > 1528: * @see #put(int,$type$[],int,int) > 1529: * @see #put(int,$Type$Buffer,int,int) Suggestion: * @see #append(CharSequence, int, int) * @see #put(int, $type$[], int, int) * @see #put(int, $Type$Buffer, int, int) src/java.base/share/classes/java/nio/X-Buffer.java.template line 1541: > 1539: > 1540: for (int i = start; i < end; i++) > 1541: this.put(index++, csq.charAt(i)); This should probably include the `String::getBytes`, `StringBuffer::getBytes`, and?`StringBuilder::getBytes` optimisation that `CharBuffer::append(CharSequece,?int,?int)`?has as?of?[JDK?8305811]?([GH?13415]) and?[JDK?8306374]?([GH?13522]). [JDK?8305811]: https://bugs.openjdk.org/browse/JDK-8305811 "[JDK?8305811] (bf) Improve performance of CharBuffer::append(CharSequence[,int,int])" [JDK?8306374]: https://bugs.openjdk.org/browse/JDK-8306374 "[JDK?8306374] (bf) Improve performance of DirectCharBuffer::append(CharSequence[,int,int])" [GH?13415]: https://github.com/openjdk/jdk/pull/13415 [GH?13522]: https://github.com/openjdk/jdk/pull/13522 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1184644247 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1184524414 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1184643591 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1184644794 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1184648752 From liach at openjdk.org Thu Jul 13 15:18:25 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: <8IsqOile1vSs_LV8hgL-rEjn1Rly1OO0aX_shMOm3l4=.9a8c56be-ca2c-46aa-9167-fd0900d691bb@github.com> On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter wrote: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. src/java.base/share/classes/java/nio/X-Buffer.java.template line 1480: > 1478: * for (int i = start, j = index; i < end; i++, j++) > 1479: * dst.put(j, csq.charAt(i)); > 1480: * } Suggestion: * {@snippet lang=java : * for (int i = start, j = index; i < end; i++, j++) * dst.put(j, csq.charAt(i)); * } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1182042410 From bpb at openjdk.org Thu Jul 13 15:18:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: <8IsqOile1vSs_LV8hgL-rEjn1Rly1OO0aX_shMOm3l4=.9a8c56be-ca2c-46aa-9167-fd0900d691bb@github.com> References: <8IsqOile1vSs_LV8hgL-rEjn1Rly1OO0aX_shMOm3l4=.9a8c56be-ca2c-46aa-9167-fd0900d691bb@github.com> Message-ID: On Tue, 2 May 2023 03:03:49 GMT, Chen Liang wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1480: > >> 1478: * for (int i = start, j = index; i < end; i++, j++) >> 1479: * dst.put(j, csq.charAt(i)); >> 1480: * } > > Suggestion: > > * {@snippet lang=java : > * for (int i = start, j = index; i < end; i++, j++) > * dst.put(j, csq.charAt(i)); > * } Good suggestion. There are however eight other occurrences of the `
    {@code ...}
    ` construct already in the file and I think I would prefer to change them all under a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1182742731 From bpb at openjdk.org Thu Jul 13 15:18:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: On Thu, 4 May 2023 04:13:47 GMT, ExE Boss wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1490: > >> 1488: *
      >> 1489: *
    • defines the range of characters to be read from the source in terms >> 1490: * of the half-open interval {@code [start,} {@code end)} instead of > > Suggestion: > > * of the half-open interval [start, end) instead of I was under the perhaps mistaken impression that `{@code ...}` is preferred to `...` these days. > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1529: > >> 1527: * @see #append(CharSequence,int,int) >> 1528: * @see #put(int,$type$[],int,int) >> 1529: * @see #put(int,$Type$Buffer,int,int) > > Suggestion: > > * @see #append(CharSequence, int, int) > * @see #put(int, $type$[], int, int) > * @see #put(int, $Type$Buffer, int, int) So changed in ef652e7. > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1541: > >> 1539: >> 1540: for (int i = start; i < end; i++) >> 1541: this.put(index++, csq.charAt(i)); > > This should probably include the `String::getBytes`, `StringBuffer::getBytes`, and?`StringBuilder::getBytes` optimisation that `CharBuffer::append(CharSequece,?int,?int)`?has as?of?[JDK?8305811]?([GH?13415]) and?[JDK?8306374]?([GH?13522]). > > [JDK?8305811]: https://bugs.openjdk.org/browse/JDK-8305811 "[JDK?8305811] (bf) Improve performance of CharBuffer::append(CharSequence[,int,int])" > [JDK?8306374]: https://bugs.openjdk.org/browse/JDK-8306374 "[JDK?8306374] (bf) Improve performance of DirectCharBuffer::append(CharSequence[,int,int])" > [GH?13415]: https://github.com/openjdk/jdk/pull/13415 > [GH?13522]: https://github.com/openjdk/jdk/pull/13522 > This should probably include the `String::getBytes`, `StringBuffer::getBytes`, and `StringBuilder::getBytes` optimisation that `CharBuffer::append(CharSequece, int, int)` has as of [JDK?8305811](https://bugs.openjdk.org/browse/JDK-8305811) ([GH?13415](https://github.com/openjdk/jdk/pull/13415)) and [JDK?8306374](https://bugs.openjdk.org/browse/JDK-8306374) ([GH?13522](https://github.com/openjdk/jdk/pull/13522)). Clearly. That's why this is a draft PR. The optimizations are intentionally omitted until consensus is achieved on the specification. I prefer not to redo the heap and direct overrides if it is at all avoidable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1185490867 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1185504217 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1185493363 From bpb at openjdk.org Thu Jul 13 15:18:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:18:24 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence Message-ID: Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. ------------- Commit messages: - 4860681: Add spaces to parameter lists in @see tag - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence Changes: https://git.openjdk.org/jdk/pull/13744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4860681 Stats: 98 lines in 1 file changed: 96 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From liach at openjdk.org Thu Jul 13 15:18:25 2023 From: liach at openjdk.org (Chen Liang) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com> On Thu, 4 May 2023 20:39:05 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1490: >> >>> 1488: *
        >>> 1489: *
      • defines the range of characters to be read from the source in terms >>> 1490: * of the half-open interval {@code [start,} {@code end)} instead of >> >> Suggestion: >> >> * of the half-open interval [start, end) instead of > > I was under the perhaps mistaken impression that `{@code ...}` is preferred to `...` these days. I think he suggested this because ` ` HTML code will not render into a no-break space in a `{@code}` block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1185508829 From bpb at openjdk.org Thu Jul 13 15:18:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:18:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com> References: <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com> Message-ID: <9nzXzvSONw8OFvrCnImESBaBOZC2uBFqbaWR6Kz0kzo=.d37c24a1-7766-40ed-b900-391503e42b57@github.com> On Thu, 4 May 2023 21:00:04 GMT, Chen Liang wrote: >> I was under the perhaps mistaken impression that `{@code ...}` is preferred to `...` these days. > > I think he suggested this because ` ` HTML code will not render into a no-break space in a `{@code}` block. And that's exactly why ` ` is not in a`{@code}` block here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1185512389 From bpb at openjdk.org Thu Jul 13 15:18:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:18:24 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter wrote: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. This pull request is initially created as a draft. Once there is consensus on the specification of the method, the draft will be marked as ready for review, labelled as requiring a CSR, and heap and direct implementations will be added along with test code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1530166801 From bpb at openjdk.org Thu Jul 13 15:24:47 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:24:47 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence In-Reply-To: References: Message-ID: On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter wrote: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. Faster implementations for direct and heap buffers will be added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1634436809 From bpb at openjdk.org Thu Jul 13 15:24:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 15:24:45 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v2] In-Reply-To: References: Message-ID: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 4860681: Modify existing test - Merge - 4860681: Add spaces to parameter lists in @see tag - 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13744/files - new: https://git.openjdk.org/jdk/pull/13744/files/ef652e76..87cbab6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=00-01 Stats: 293254 lines in 5219 files changed: 211564 ins; 45297 del; 36393 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From bpb at openjdk.org Thu Jul 13 19:28:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 19:28:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v3] In-Reply-To: <9nzXzvSONw8OFvrCnImESBaBOZC2uBFqbaWR6Kz0kzo=.d37c24a1-7766-40ed-b900-391503e42b57@github.com> References: <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com> <9nzXzvSONw8OFvrCnImESBaBOZC2uBFqbaWR6Kz0kzo=.d37c24a1-7766-40ed-b900-391503e42b57@github.com> Message-ID: On Thu, 4 May 2023 21:03:11 GMT, Brian Burkhalter wrote: >> I think he suggested this because ` ` HTML code will not render into a no-break space in a `{@code}` block. > > And that's exactly why ` ` is not in a`{@code}` block here. Line breaking addressed by 831cea6f7eabff6317af1ba309b2e9294b568671. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1262970391 From bpb at openjdk.org Thu Jul 13 19:28:25 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 19:28:25 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v3] In-Reply-To: References: Message-ID: On Thu, 4 May 2023 07:30:52 GMT, ExE Boss wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4860681: Change some {@code ...} to ... to prevent line breaking > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1463: > >> 1461: * that is, if >> 1462: * end - start {@code >}  >> 1463: * {@code limit()} - {@code index}, > > Suggestion: > > * end - start > limit() - index, Line breaking addressed by 831cea6f7eabff6317af1ba309b2e9294b568671. > src/java.base/share/classes/java/nio/X-Buffer.java.template line 1495: > >> 1493: * {@code IndexOutOfBoundsException} for the condition >> 1494: * {@code index} {@code +} {@code end} {@code -}  >> 1495: * {@code start} {@code >} {@code limit()}.
      • > > Suggestion: > > * index + end - start > limit(). Line breaking addressed by 831cea6f7eabff6317af1ba309b2e9294b568671. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1262970571 PR Review Comment: https://git.openjdk.org/jdk/pull/13744#discussion_r1262970737 From bpb at openjdk.org Thu Jul 13 19:28:24 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 13 Jul 2023 19:28:24 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v3] In-Reply-To: References: Message-ID: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4860681: Change some {@code ...} to ... to prevent line breaking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13744/files - new: https://git.openjdk.org/jdk/pull/13744/files/87cbab6a..831cea6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=01-02 Stats: 12 lines in 1 file changed: 1 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From alanb at openjdk.org Fri Jul 14 10:27:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Jul 2023 10:27:54 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 16:17:49 GMT, Glavo wrote: >> Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). >> To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. >> Without that it could be that somebody else starts the discussion again. >> >> This is just a suggestion to be explicit as it makes maintaining the code easier. > >> Maybe a small suggestion to make it clear whats wanted here. In other projects I am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle itsself, Elasticserach/Opensearch), which use the [forbiddenapis Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), we forbid all calls to several Java APIs (including toLowerCase/toUpperCase case). All bytecode using this will build failure (FYI, we also disallow other stuff like relying of default timezone or characterset). To make it clear what is really intended, those projects agreed on having `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. Without that it could be that somebody else starts the discussion again. >> >> This is just a suggestion to be explicit as it makes maintaining the code easier. > > I agree with this. > > I'm working on deprecating `toLowerCase()` and `toUpperCase()`, this PR is part of that effort. I wish to convert all use cases of them to `toLowerCase(Locale)` and `toUpperCase(Locale)`. > > More backstory is detailed in https://github.com/openjdk/jdk/pull/13434#issuecomment-1503989660. > However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. StreamTokenizer is a very old API and changing long standing behavior may break something or be observable with existing code/usages. I see youve reverted this part (thanks) and looking at it separately is fine. It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263570865 From prappo at openjdk.org Fri Jul 14 12:21:32 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 12:21:32 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code Message-ID: Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. Please note, test results are pending. Additional notes: * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. ------------- Commit messages: - Fix a doc comment - Initial commit Changes: https://git.openjdk.org/jdk/pull/14886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312089 Stats: 129 lines in 14 files changed: 12 ins; 69 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/14886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14886/head:pull/14886 PR: https://git.openjdk.org/jdk/pull/14886 From prappo at openjdk.org Fri Jul 14 12:21:32 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 12:21:32 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. > > Please note, test results are pending. > > Additional notes: > > * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. > > * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. > > * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. > > * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. src/java.base/share/classes/java/nio/charset/Charset.java line 963: > 961: > 962: /** > 963: * {@return Computes a hashcode for this charset} Oops. Should be this instead: {@return a hashcode for this charset} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263662782 From alanb at openjdk.org Fri Jul 14 12:41:01 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Jul 2023 12:41:01 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. > > Please note, test results are pending. > > Additional notes: > > * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. > > * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. > > * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. > > * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. src/java.base/share/classes/java/nio/charset/Charset.java line 957: > 955: * is less than, equal to, or greater than the specified charset > 956: */ > 957: @Override This PR adds `@Override` to a subset of the overridden methods, probably best to add it to all overridden methods so we don't end up with a mix. src/java.base/share/classes/java/nio/charset/Charset.java line 963: > 961: > 962: /** > 963: * {@return a hashcode for this charset} If you changing this then probably better to use "the hashcode". src/java.base/share/classes/java/nio/file/attribute/FileTime.java line 368: > 366: return cmp; > 367: } > 368: return Long.compare(toExcessNanos(days), other.toExcessNanos(daysOther)); Maybe a coin toss, but I think the original code was a bit clearer. src/java.base/unix/classes/sun/nio/fs/UnixFileKey.java line 53: > 51: if (!(obj instanceof UnixFileKey other)) > 52: return false; > 53: return (this.st_dev == other.st_dev) && (this.st_ino == other.st_ino); Style-wise, I think usages like this are a bit easier to read. return obj instanceof UnixFileKey other && (this.st_dev == other.st_dev) && (this.st_ino == other.st_ino); src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 712: > 710: int thatPos = that.offsets[0]; > 711: return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos, > 712: thatLen); Might be cleaner to not put a line break here. src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 731: > 729: if (h == 0) { > 730: h = ArraysSupport.vectorizedHashCode(path, 0, path.length, 0, > 731: ArraysSupport.T_BOOLEAN); Can you make this `/* unsigned bytes */ ArraysSupport.T_BOOLEAN`, or `ArraysSupport.T_BOOLEAN); // unsigned bytes`, only because T_BOOLEAN isn't always obvious as use-sites. src/java.base/windows/classes/sun/nio/ch/FileKey.java line 52: > 50: return (int)(dwVolumeSerialNumber ^ (dwVolumeSerialNumber >>> 32)) + > 51: (int)(nFileIndexHigh ^ (nFileIndexHigh >>> 32)) + > 52: (int)(nFileIndexLow ^ (nFileIndexLow >>> 32)); Well spotted, probably a cut and paste error at some point, but benign, the resulting hash code is still okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263667696 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263666839 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263677841 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263671563 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263679533 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263684952 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263680738 From alanb at openjdk.org Fri Jul 14 12:49:26 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Jul 2023 12:49:26 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v4] In-Reply-To: References: Message-ID: On Wed, 12 Jul 2023 17:09:25 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Attempt to improve specifications of varargs resolve methods src/java.base/share/classes/java/nio/file/Path.java line 521: > 519: /** > 520: * Resolves one or more {@code Path}s iteratively against this > 521: * {@code Path}. If {@code more} does not specify any {@code Path}s, The. updated text looks much better but I think we need to make it clearer that it's only "first" that is resolved against this path. How about this for the first sentence: "Resolves a path against this path, and then iteratively resolves any additional paths". This is deliberately brief to avoid a complicated first sentence. src/java.base/share/classes/java/nio/file/Path.java line 552: > 550: * @param more additional paths to be iteratively resolved against this path > 551: * > 552: * @return the resulting path Minor comment is that @param/@return style is a bit different to the other methods. src/java.base/share/classes/java/nio/file/Path.java line 568: > 566: /** > 567: * Resolves one or more {@code Path}s converted from the supplied path > 568: * srings iteratively against this {@code Path}. If {@code more} does not How about "Converts a path string to a Path, resolves it against this path, and then iteratively converts and resolves any additional path strings" ? src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 398: > 396: } > 397: > 398: private static final byte[] resolve(byte[] base, byte[]... descendants) { When doing resolution, the term used is often "child". The existing 2-arg resolve uses "child" for example. So I think this should be renamed to "children". src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 402: > 400: // descendant is that last one which is an absolute path > 401: int start = 0; > 402: int length = base.length; One suggestion here is to rename this to "resultLength". src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 409: > 407: if (count > 0) { > 408: for (int i = 0; i < count; i++) { > 409: byte[] b = descendants[i]; This can be renamed to "child". src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 428: > 426: // account for an extra '/' added in the length computation. > 427: if (start == 0 && length > base.length && > 428: base.length == 1 && base[0] == '/') The line break make is very hard to read. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263610126 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263611298 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263614505 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263619666 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263693991 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263692334 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263615119 From duke at openjdk.org Fri Jul 14 13:05:14 2023 From: duke at openjdk.org (Glavo) Date: Fri, 14 Jul 2023 13:05:14 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 10:24:47 GMT, Alan Bateman wrote: > It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future. Until we're sure we want to normalize a usage of `toLowerCase()` to one of `toLowerCase(Locale.ROOT)` or `toLowerCase(Locale.getDefault())`, I think it should be left here as-is, thus keeping it in an ambiguous state to remind us to continue discussing it in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263710911 From prappo at openjdk.org Fri Jul 14 13:16:27 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 13:16:27 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v2] In-Reply-To: References: Message-ID: > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. > > Please note, test results are pending. > > Additional notes: > > * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. > > * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. > > * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. > > * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: - Address another case from feedback - Address feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14886/files - new: https://git.openjdk.org/jdk/pull/14886/files/ad22456d..a39780f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=00-01 Stats: 21 lines in 6 files changed: 3 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/14886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14886/head:pull/14886 PR: https://git.openjdk.org/jdk/pull/14886 From duke at openjdk.org Fri Jul 14 13:18:08 2023 From: duke at openjdk.org (Glavo) Date: Fri, 14 Jul 2023 13:18:08 GMT Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 13:01:46 GMT, Glavo wrote: >>> However, while I think this corrects the behavior, this caused a change in the behavior of the API, so a CSR may be required. I don't want to debate this in this PR, so I'll revert this change and open a new PR in the future. >> >> StreamTokenizer is a very old API and changing long standing behavior may break something or be observable with existing code/usages. I see youve reverted this part (thanks) and looking at it separately is fine. It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future. > >> It might be that the conclusion is that it's just too risky to change, in which case Uwe's suggestion is good and would avoid it showing up on someone's else radar in the future. > > Until we're sure we want to normalize a usage of `toLowerCase()` to one of `toLowerCase(Locale.ROOT)` or `toLowerCase(Locale.getDefault())`, I think it should be left here as-is, thus keeping it in an ambiguous state to remind us to continue discussing it in the future. If we can't normalize this use case to be locale-independent, then I even think `lowerCaseMode` should be deprecated, because it's almost impossible for users to get expected behavior with this method. In order to make it meaningful, I think it is still necessary to consider making it locale insensitive. We can allow users to fall back to the old behavior through new system properties, or introduce new API methods in `StreamTokenizer` to allow users to set the Locale to be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1263725166 From forax at univ-mlv.fr Fri Jul 14 13:29:27 2023 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Jul 2023 15:29:27 +0200 (CEST) Subject: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] In-Reply-To: References: Message-ID: <1059971530.104670971.1689341367155.JavaMail.zimbra@univ-eiffel.fr> ----- Original Message ----- > From: "Uwe Schindler" > To: "core-libs-dev" , net-dev at openjdk.org, nio-dev at openjdk.org, security-dev at openjdk.org > Sent: Wednesday, July 12, 2023 6:08:17 PM > Subject: Re: RFR: 8311943: Cleanup usages of toLowerCase() and toUpperCase() in java.base [v2] > On Wed, 12 Jul 2023 14:31:53 GMT, Glavo wrote: > >>> src/java.base/share/classes/java/io/StreamTokenizer.java line 632: >>> >>>> 630: sval = String.copyValueOf(buf, 0, i); >>>> 631: if (forceLower) >>>> 632: sval = sval.toLowerCase(Locale.ROOT); >>> >>> I suspect this change to StreamTokenizer needs eyes. I think long standing >>> behavior of the lowerCaseMode(true) has been to use the rules for the default >>> locale so we need to be careful. >> >>> I suspect this change to StreamTokenizer needs eyes. I think long standing >>> behavior of the lowerCaseMode(true) has been to use the rules for the default >>> locale so we need to be careful. >> >> I investigated usage of this method on GitHub: >> >> https://github.com/search?q=%22lowerCaseMode%28true%29%22+language%3AJava&type=code >> >> In some of the use cases I investigated, it seems that no one wants to rely on >> the default locale. >> >> However, while I think this corrects the behavior, this caused a change in the >> behavior of the API, so a CSR may be required. I don't want to debate this in >> this PR, so I'll revert this change and open a new PR in the future. > > Maybe a small suggestion to make it clear whats wanted here. In other projects I > am involved in (Apache Lucene/Solr, Apache TIKA, PostgresSQL JDBC, Checkstyle > itsself, Elasticserach/Opensearch), which use the [forbiddenapis > Maven/Gradle/Ant plugin](https://github.com/policeman-tools/forbidden-apis/), > we forbid all calls to several Java APIs (including toLowerCase/toUpperCase > case). All bytecode using this will build failure (FYI, we also disallow other > stuff like relying of default timezone or characterset). > To make it clear what is really intended, those projects agreed on having > `toLowerCase(Locale.getDefault())`, so it is explicit what's wanted. > Without that it could be that somebody else starts the discussion again. > > This is just a suggestion to be explicit as it makes maintaining the code > easier. One solution is to deprecate String.toLowerCase()/toUpperCase(), forcing users to explicitly use the variants that takes a Locale. Obviously, I'm talking about a simple deprecation not a deprecation for removal. R?mi > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/14763#discussion_r1261404900 From prappo at openjdk.org Fri Jul 14 14:46:14 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 14:46:14 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v2] In-Reply-To: References: Message-ID: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com> On Fri, 14 Jul 2023 13:16:27 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. >> >> Please note, test results are pending. >> >> Additional notes: >> >> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. >> >> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. >> >> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. >> >> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. >> >> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. >> >> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Address another case from feedback > - Address feedback > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. @AlanBateman, what do you think of that? For convenience, let me paste here relevant source parts: /** ... *

        Every charset has a canonical name and may also have one or more * aliases. The canonical name is returned by the {@link #name() name} method * of this class. Canonical names are, by convention, usually in upper case. * The aliases of a charset are returned by the {@link #aliases() aliases} * method. ... */ public abstract class Charset implements Comparable { ... /** * Compares this charset to another. * *

        Charsets are ordered by their canonical names, without regard to * case. ... */ @Override public final int compareTo(Charset that) { return (name().compareToIgnoreCase(that.name())); } ... /** * Tells whether or not this object is equal to another. * *

        Two charsets are equal if, and only if, they have the same canonical * names. A charset is never equal to any other type of object.

        * * @return {@code true} if, and only if, this charset is equal to the * given object */ @Override public final boolean equals(Object ob) { if (this == ob) return true; return ob instanceof Charset other && name.equals(other.name()); } ... } Here's what Comparable has to say about this: public interface Comparable { /** ... * @apiNote * It is strongly recommended, but not strictly required that * {@code (x.compareTo(y)==0) == (x.equals(y))}. Generally speaking, any * class that implements the {@code Comparable} interface and violates * this condition should clearly indicate this fact. The recommended * language is "Note: this class has a natural ordering that is * inconsistent with equals." ... */ public int compareTo(T o); ------------- PR Comment: https://git.openjdk.org/jdk/pull/14886#issuecomment-1635967137 From bpb at openjdk.org Fri Jul 14 15:54:20 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 15:54:20 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v4] In-Reply-To: References: Message-ID: > Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4860681: Heap and direct buffer specializations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13744/files - new: https://git.openjdk.org/jdk/pull/13744/files/831cea6f..9e1ce482 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13744&range=02-03 Stats: 80 lines in 2 files changed: 79 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13744/head:pull/13744 PR: https://git.openjdk.org/jdk/pull/13744 From bpb at openjdk.org Fri Jul 14 15:54:22 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 15:54:22 GMT Subject: RFR: 4860681: (bf) Add CharBuffer absolute bulk put method for CharSequence [v3] In-Reply-To: References: Message-ID: On Thu, 13 Jul 2023 19:28:24 GMT, Brian Burkhalter wrote: >> Add to `java.nio.CharBuffer` an absolute bulk put method which takes a `CharSequence` as its source of `char`s. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4860681: Change some {@code ...} to ... to prevent line breaking Performance of heap and direct buffer specializations versus generic `X-Buffer` changes only: ```Generic X-Buffer changes only Benchmark (length) Mode Cnt Score Error Units PutCharSequence.putDirect 1024 thrpt 5 2655951.820 ? 30551.074 ops/s PutCharSequence.putDirect 32768 thrpt 5 87286.331 ? 1493.683 ops/s PutCharSequence.putDirect 65536 thrpt 5 41029.857 ? 587.599 ops/s PutCharSequence.putHeap 1024 thrpt 5 2048416.307 ? 9127.354 ops/s PutCharSequence.putHeap 32768 thrpt 5 104206.140 ? 2945.981 ops/s PutCharSequence.putHeap 65536 thrpt 5 52126.813 ? 1899.363 ops/s Heap and Direct specializations Benchmark (length) Mode Cnt Score Error Units PutCharSequence.putDirect 1024 thrpt 5 4990301.930 ? 183735.783 ops/s PutCharSequence.putDirect 32768 thrpt 5 318722.656 ? 8077.988 ops/s PutCharSequence.putDirect 65536 thrpt 5 155942.514 ? 9393.195 ops/s PutCharSequence.putHeap 1024 thrpt 5 28828706.355 ? 625628.365 ops/s PutCharSequence.putHeap 32768 thrpt 5 725648.311 ? 24331.955 ops/s PutCharSequence.putHeap 65536 thrpt 5 433791.513 ? 5310.098 ops/s ------------- PR Comment: https://git.openjdk.org/jdk/pull/13744#issuecomment-1636050679 From alanb at openjdk.org Fri Jul 14 15:55:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Jul 2023 15:55:16 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v2] In-Reply-To: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com> References: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com> Message-ID: On Fri, 14 Jul 2023 14:42:47 GMT, Pavel Rappo wrote: > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > @AlanBateman, what do you think of that? For convenience, let me paste here relevant source parts: There are a few classes where the natural ordering is not consistent with equals. For another PR, this could be documented as it is done in other classes. n practical terms then it's probably not a concern because the canonical name will usually be a charset name registered with IANA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14886#issuecomment-1636053904 From bpb at openjdk.org Fri Jul 14 16:49:05 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 16:49:05 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v5] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Improve verbiage per reviewer PR comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/09704e08..f78894c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=03-04 Stats: 46 lines in 2 files changed: 9 ins; 1 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Fri Jul 14 16:49:13 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 16:49:13 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v4] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 11:11:22 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262742: Attempt to improve specifications of varargs resolve methods > > src/java.base/share/classes/java/nio/file/Path.java line 521: > >> 519: /** >> 520: * Resolves one or more {@code Path}s iteratively against this >> 521: * {@code Path}. If {@code more} does not specify any {@code Path}s, > > The. updated text looks much better but I think we need to make it clearer that it's only "first" that is resolved against this path. How about this for the first sentence: "Resolves a path against this path, and then iteratively resolves any additional paths". This is deliberately brief to avoid a complicated first sentence. Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/share/classes/java/nio/file/Path.java line 552: > >> 550: * @param more additional paths to be iteratively resolved against this path >> 551: * >> 552: * @return the resulting path > > Minor comment is that @param/@return style is a bit different to the other methods. Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/share/classes/java/nio/file/Path.java line 568: > >> 566: /** >> 567: * Resolves one or more {@code Path}s converted from the supplied path >> 568: * srings iteratively against this {@code Path}. If {@code more} does not > > How about "Converts a path string to a Path, resolves it against this path, and then iteratively converts and resolves any additional path strings" ? Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 398: > >> 396: } >> 397: >> 398: private static final byte[] resolve(byte[] base, byte[]... descendants) { > > When doing resolution, the term used is often "child". The existing 2-arg resolve uses "child" for example. So I think this should be renamed to "children". Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 402: > >> 400: // descendant is that last one which is an absolute path >> 401: int start = 0; >> 402: int length = base.length; > > One suggestion here is to rename this to "resultLength". Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 409: > >> 407: if (count > 0) { >> 408: for (int i = 0; i < count; i++) { >> 409: byte[] b = descendants[i]; > > This can be renamed to "child". Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 428: > >> 426: // account for an extra '/' added in the length computation. >> 427: if (start == 0 && length > base.length && >> 428: base.length == 1 && base[0] == '/') > > The line break make is very hard to read. Addressed in f78894c86eeeb4c94ed417eae43793c9dd1c80ee. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933203 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933271 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933418 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933651 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933816 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933733 PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1263933541 From alanb at openjdk.org Fri Jul 14 18:01:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Jul 2023 18:01:15 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 13:16:27 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. >> >> Please note, test results are pending. >> >> Additional notes: >> >> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. >> >> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. >> >> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. >> >> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. >> >> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. >> >> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. > > Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: > > - Address another case from feedback > - Address feedback src/java.base/share/classes/java/nio/charset/Charset.java line 987: > 985: > 986: /** > 987: * {@return the string describing this charset} You've changed this to "the string", which hints of ==, I think it should be reverted to a "a string". src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 713: > 711: > 712: return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos, > 713: thatLen); My comment here was "thatLen" ended up on its own line, it can go after thatPos without making it too long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263932426 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1263936625 From prappo at openjdk.org Fri Jul 14 18:54:35 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 18:54:35 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v3] In-Reply-To: References: Message-ID: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com> > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. > > Please note, test results are pending. > > Additional notes: > > * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. > > * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. > > * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. > > * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Re-address feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14886/files - new: https://git.openjdk.org/jdk/pull/14886/files/a39780f5..8c171ae5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14886&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14886/head:pull/14886 PR: https://git.openjdk.org/jdk/pull/14886 From prappo at openjdk.org Fri Jul 14 18:54:41 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 14 Jul 2023 18:54:41 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v2] In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 16:42:02 GMT, Alan Bateman wrote: >> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address another case from feedback >> - Address feedback > > src/java.base/share/classes/java/nio/charset/Charset.java line 987: > >> 985: >> 986: /** >> 987: * {@return the string describing this charset} > > You've changed this to "the string", which hints of ==, I think it should be reverted to a "a string". Never understood this a/the difference in doc comments, thanks for explaining it. > src/java.base/unix/classes/sun/nio/fs/UnixPath.java line 713: > >> 711: >> 712: return Arrays.equals(this.path, thisPos, thisLen, that.path, thatPos, >> 713: thatLen); > > My comment here was "thatLen" ended up on its own line, it can go after thatPos without making it too long. That was surprising considering how picky you are about being on the shorter side of line widths. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1264042654 PR Review Comment: https://git.openjdk.org/jdk/pull/14886#discussion_r1264044071 From bpb at openjdk.org Fri Jul 14 22:16:11 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 22:16:11 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v4] In-Reply-To: References: Message-ID: > In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. 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 seven additional commits since the last revision: - 8136895: Simplify change to implClose() - Merge - 8136895: Tweak to StreamEncoder::implCose - 8136895: Small improvements to StreamEncoderClose test - 8136895: Trivial formatting corrections in tests - 8136895: Do not swallow exceptions in StreamEncoder::implFlush; add test for OutputStreamWriter; rename test for Channels::newWriter" - 8136895: Writer not closed with disk full error, file resource leaked ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13503/files - new: https://git.openjdk.org/jdk/pull/13503/files/4c8ab6df..d1965996 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13503&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13503&range=02-03 Stats: 419758 lines in 6343 files changed: 267956 ins; 107764 del; 44038 mod Patch: https://git.openjdk.org/jdk/pull/13503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13503/head:pull/13503 PR: https://git.openjdk.org/jdk/pull/13503 From bpb at openjdk.org Fri Jul 14 22:16:28 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 14 Jul 2023 22:16:28 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v3] In-Reply-To: References: Message-ID: <63iX12Vms8a0Wfnhh1TN9FQaYRAQvKPxIIcaL9HRDd4=.f1d55857-3aba-4b08-8d73-9262181eb727@github.com> On Thu, 27 Apr 2023 06:52:16 GMT, Daniel Jeli?ski wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8136895: Trivial formatting corrections in tests > > This is what I had in mind: > > --- a/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java > +++ b/src/java.base/share/classes/sun/nio/cs/StreamEncoder.java > @@ -414,8 +414,7 @@ public final class StreamEncoder extends Writer { > } > > void implClose() throws IOException { > - IOException ioe = null; > - try { > + try (ch; out) { > flushLeftoverChar(null, true); > for (;;) { > CoderResult cr = encoder.flush(bb); > @@ -433,28 +432,7 @@ public final class StreamEncoder extends Writer { > writeBytes(); > } catch (IOException x) { > encoder.reset(); > - ioe = x; > } > - > - try { > - if (ch != null) > - ch.close(); > - else { > - try { > - out.flush(); > - } finally { > - out.close(); > - } > - } > - } catch (IOException e) { > - if (ioe != null) > - ioe.addSuppressed(e); > - else > - ioe = e; > - } > - > - if (ioe != null) > - throw ioe; > } > > String encodingName() { > > (yes it still makes `StreamEncoderClose` test fail) Commit d19659963b8a2a2cea11208459d33f1ca8c1af10 changes `implClose()` along the lines suggested by @djelinski . The `close()` is handled by a `try-with-resources` block. This assumes that any flushing of the channel or output stream would be done by the `close()` of the respective destination. The bytes held in `bb` will not, as mentioned above, be flushed. This change passes all NIO tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13503#issuecomment-1636502450 From alanb at openjdk.org Sat Jul 15 07:07:03 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 15 Jul 2023 07:07:03 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v3] In-Reply-To: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com> References: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com> Message-ID: On Fri, 14 Jul 2023 18:54:35 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. >> >> Please note, test results are pending. >> >> Additional notes: >> >> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. >> >> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. >> >> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. >> >> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. >> >> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. >> >> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Re-address feedback Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14886#pullrequestreview-1531305811 From alanb at openjdk.org Sat Jul 15 07:14:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 15 Jul 2023 07:14:09 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v5] In-Reply-To: References: Message-ID: <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com> On Fri, 14 Jul 2023 16:49:05 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Improve verbiage per reviewer PR comments src/java.base/share/classes/java/nio/file/Path.java line 527: > 525: * {@code more} specifies one or more {@code Path}s, then each non-empty > 526: * {@code Path}, including {@code first}, is resolved iteratively against > 527: * this {@code Path}. The second paragraph has the same issue as before, it says "resolved iteratively against this Path" but that isn't correct. Same issue in the description of the "more" method. The first paragraph is correct, and I think we'll need to re-phrase the second paragraph to accurate specify how the iterative resolution works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1264348985 From vtewari at openjdk.org Sun Jul 16 11:34:18 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Sun, 16 Jul 2023 11:34:18 GMT Subject: RFR: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code [v3] In-Reply-To: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com> References: <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com> Message-ID: On Fri, 14 Jul 2023 18:54:35 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. >> >> Please note, test results are pending. >> >> Additional notes: >> >> * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. >> >> * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. >> >> * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. >> >> * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. >> >> * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. >> >> * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. > > Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: > > Re-address feedback Looks OK to me. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/14886#pullrequestreview-1531726844 From djelinski at openjdk.org Mon Jul 17 06:11:24 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 17 Jul 2023 06:11:24 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v4] In-Reply-To: References: Message-ID: <4nfS28vNfmvhJQIIYlAvdGMfYqNUbF5J1hFh6FFx-4k=.1490f91a-b237-4605-b3dc-0aca569051b3@github.com> On Fri, 14 Jul 2023 22:16:11 GMT, Brian Burkhalter wrote: >> In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. > > 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 seven additional commits since the last revision: > > - 8136895: Simplify change to implClose() > - Merge > - 8136895: Tweak to StreamEncoder::implCose > - 8136895: Small improvements to StreamEncoderClose test > - 8136895: Trivial formatting corrections in tests > - 8136895: Do not swallow exceptions in StreamEncoder::implFlush; add test for OutputStreamWriter; rename test for Channels::newWriter" > - 8136895: Writer not closed with disk full error, file resource leaked Can you remove the explicit calls to `close()`? The underlying stream/channel is now closed twice in the no-exception case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13503#issuecomment-1637433281 From alanb at openjdk.org Mon Jul 17 10:37:20 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 17 Jul 2023 10:37:20 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive Message-ID: DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/14901/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14901&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312166 Stats: 344 lines in 2 files changed: 149 ins; 141 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/14901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14901/head:pull/14901 PR: https://git.openjdk.org/jdk/pull/14901 From bpb at openjdk.org Mon Jul 17 17:23:20 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 17:23:20 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v4] In-Reply-To: <4nfS28vNfmvhJQIIYlAvdGMfYqNUbF5J1hFh6FFx-4k=.1490f91a-b237-4605-b3dc-0aca569051b3@github.com> References: <4nfS28vNfmvhJQIIYlAvdGMfYqNUbF5J1hFh6FFx-4k=.1490f91a-b237-4605-b3dc-0aca569051b3@github.com> Message-ID: On Mon, 17 Jul 2023 06:08:21 GMT, Daniel Jeli?ski wrote: > Can you remove the explicit calls to `close()`? The underlying stream/channel is now closed twice in the no-exception case. Will do. That was an oversight to leave them in. Thanks for pointing it out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13503#issuecomment-1638560937 From bpb at openjdk.org Mon Jul 17 17:52:42 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 17:52:42 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: > In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8136895: Remove vestigial explicit calls to close() in implClose() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13503/files - new: https://git.openjdk.org/jdk/pull/13503/files/d1965996..a400b04e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13503&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13503&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13503/head:pull/13503 PR: https://git.openjdk.org/jdk/pull/13503 From djelinski at openjdk.org Mon Jul 17 17:59:56 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 17 Jul 2023 17:59:56 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter wrote: >> In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8136895: Remove vestigial explicit calls to close() in implClose() LGTM. ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13503#pullrequestreview-1533374885 From bpb at openjdk.org Mon Jul 17 18:32:15 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 18:32:15 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:57:32 GMT, Daniel Jeli?ski wrote: > LGTM. Thanks. This change passes all NIO tests as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13503#issuecomment-1638658719 From bpb at openjdk.org Mon Jul 17 19:10:41 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 19:10:41 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v6] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Try to improve specifications of varargs resolve()s ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/f78894c8..0fa126fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=04-05 Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Mon Jul 17 19:10:46 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 19:10:46 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v5] In-Reply-To: <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com> References: <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com> Message-ID: On Sat, 15 Jul 2023 07:11:03 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262742: Improve verbiage per reviewer PR comments > > src/java.base/share/classes/java/nio/file/Path.java line 527: > >> 525: * {@code more} specifies one or more {@code Path}s, then each non-empty >> 526: * {@code Path}, including {@code first}, is resolved iteratively against >> 527: * this {@code Path}. > > The second paragraph has the same issue as before, it says "resolved iteratively against this Path" but that isn't correct. Same issue in the description of the "more" method. The first paragraph is correct, and I think we'll need to re-phrase the second paragraph to accurate specify how the iterative resolution works. 0fa126fd2d3861c56b85093e8a2483afa1ad9ef6 attempts to improve the aforementioned verbiage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1265788140 From bpb at openjdk.org Mon Jul 17 21:18:31 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 21:18:31 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v7] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Add some cases to the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/0fa126fd..505d72b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=05-06 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Mon Jul 17 21:18:55 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Jul 2023 21:18:55 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> Message-ID: On Wed, 12 Jul 2023 00:48:30 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/file/Path/PathOps.java line 1728: >> >>> 1726: .resolve("/foo", "", "foo") >>> 1727: .resolve("/bar", "foo", "", "/bar"); >>> 1728: >> >> Should there be test cases that include multiple directories in a path: "abc/def/xyz"? >> Also cases with "..", or is that only relevant if canonicalizing. > > Multiple directories would be good but I don't know about `..`. > Should there be test cases that include multiple directories in a path: "abc/def/xyz"? Added some multiple directory cases in 505d72b48c5d34bbf4474c6fed43e2f269e8e135. > Also cases with ".." This is not relevant. For example, using the existing `resolve(Path)`: jshell> java.nio.file.Path.of("/tmp").resolve("..").resolve("..") $1 ==> /tmp/../.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1265912379 From prappo at openjdk.org Mon Jul 17 22:31:17 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 17 Jul 2023 22:31:17 GMT Subject: Integrated: 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code In-Reply-To: References: Message-ID: On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for in java.nio and implementation code. > > Please note, test results are pending. > > Additional notes: > > * This PR saves a volatile read in java.nio.file.attribute.AclEntry.hashCode. Not that it's too important, but worth noting because of rearrangements. > > * java.nio.charset.Charset#compareTo seems **inconsistent** with equals. If so, I cannot see where that inconsistency is specified. > > * Is this a **bug** in sun.nio.ch.FileKey#hashCode? Tell me if not, I'll revert it. > > * This PR simplifies the tail of java.nio.file.attribute.FileTime.compareTo. Unless I'm missing something, that comment in source above the affected lines **seems** not to prohibit such a simplification. > > * sun.nio.fs.UnixFileStore#hashCode does not include entry.name(). While it's not wrong, I wonder if it was on purpose. > > * Despite its title, this PR also and opportunistically refactors sun.nio.fs.UnixPath.endsWith. This pull request has now been integrated. Changeset: 5cc71f81 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/5cc71f817ff97a17a9f1dfc72a6f10ebe701baaa Stats: 136 lines in 14 files changed: 13 ins; 74 del; 49 mod 8312089: Simplify and modernize equals, hashCode, and compareTo in java.nio and implementation code Reviewed-by: alanb, vtewari ------------- PR: https://git.openjdk.org/jdk/pull/14886 From tsteele at openjdk.org Mon Jul 17 22:58:18 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 17 Jul 2023 22:58:18 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) Message-ID: Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... [emphasis added by me] By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. ------------- Commit messages: - Revert "Trigger GHA re-build" - Trigger GHA re-build - Minor fixup - Adds platform dependant pageSize call to MappedMemoryUtils Changes: https://git.openjdk.org/jdk/pull/14904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8312180 Stats: 27 lines in 3 files changed: 26 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14904/head:pull/14904 PR: https://git.openjdk.org/jdk/pull/14904 From tsteele at openjdk.org Mon Jul 17 23:02:06 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 17 Jul 2023 23:02:06 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele wrote: > Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > >> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... > [emphasis added by me] > > By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. The pre-test failures appearing on some architectures may be using old header files and need to be re-run. I encountered a similar issue internally, and fixed it with `make clean`. In any case, I don't think the signature can be wrong on linux-x[86|64], but right on linux-x64-hs* since they use the same source. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1639001282 From tsteele at openjdk.org Mon Jul 17 23:26:21 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 17 Jul 2023 23:26:21 GMT Subject: RFR: 8309475: [aix] Test java/foreign/TestByteBuffer.java fails: a problem with msync Message-ID: Solves the issue by searching `/proc//map` for the map after an EINVAL. If the map is marked `MAP_PRIVATE` then EINVAL is ignored. ------------- Depends on: https://git.openjdk.org/jdk/pull/14904 Commit messages: - Remove dead code - Adds error validation for after call to force0 on AIX (msync) Changes: https://git.openjdk.org/jdk/pull/14914/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14914&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309475 Stats: 71 lines in 1 file changed: 71 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14914.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14914/head:pull/14914 PR: https://git.openjdk.org/jdk/pull/14914 From bpb at openjdk.org Tue Jul 18 02:12:12 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 18 Jul 2023 02:12:12 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele wrote: > Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > >> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... > [emphasis added by me] > > By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 172: > 170: private static int pageSize() { > 171: int ps = pageSize0(); > 172: if (ps > 0) { If `sysconf(_SC_PAGESIZE)` returns a value different from `Bits::pageSize` on other Unix platforms, this could cause an unexpected change in behavior. src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 175: > 173: return ps; > 174: } else { > 175: return Bits.pageSize(); `Bits::pageSize` returns `UnsafeConstants::PAGE_SIZE` which is injected by the VM. Could it be that that value is somehow derived differently on AIX? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266098076 PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266098155 From alanb at openjdk.org Tue Jul 18 05:37:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 05:37:11 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele wrote: > Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > >> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... > [emphasis added by me] > > By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. This change impacts all platforms and I think needs more information. How many page sizes are you dealing with on AIX, what does Unsafe::pageSize return vs. sysconf(_SC_PAGESIZE). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1639514825 From vtewari at openjdk.org Tue Jul 18 05:41:05 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Tue, 18 Jul 2023 05:41:05 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter wrote: >> In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8136895: Remove vestigial explicit calls to close() in implClose() test/jdk/java/io/OutputStreamWriter/CloseWriterOnFailedFlush.java line 27: > 25: * @bug 8136895 > 26: * @summary Verify stream closed after write error in StreamEncoder::implClose > 27: */ Do you mind adding action tag(@run) ? test/jdk/java/nio/channels/Channels/CloseWriterOnFailedFlush.java line 27: > 25: * @bug 8136895 > 26: * @summary Verify channel closed after write error in StreamEncoder::implClose > 27: */ Do you mind adding action tag(@run) ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13503#discussion_r1266246130 PR Review Comment: https://git.openjdk.org/jdk/pull/13503#discussion_r1266245444 From vtewari at openjdk.org Tue Jul 18 05:48:13 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Tue, 18 Jul 2023 05:48:13 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter wrote: >> In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8136895: Remove vestigial explicit calls to close() in implClose() Code changes looks OK to me, i tested with the Test provided by original submitter and after fix i see underline file descriptors are getting closed. ------------- Marked as reviewed by vtewari (Committer). PR Review: https://git.openjdk.org/jdk/pull/13503#pullrequestreview-1534219343 From duke at openjdk.org Tue Jul 18 05:51:06 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 18 Jul 2023 05:51:06 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v6] In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 19:10:41 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Try to improve specifications of varargs resolve()s src/java.base/share/classes/java/nio/file/Path.java line 527: > 525: * {@code more} specifies one or more {@code Path}s, then {@code first} > 526: * is resolved against this path and then the additional paths in > 527: * {@code more} are iteratively resolved. Does?the?following better?describe?what this?method?does? Suggestion: * {@code more} are iteratively resolved against the previous path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1266250927 From jpai at openjdk.org Tue Jul 18 13:41:14 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 13:41:14 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman wrote: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. These changes look OK to me. The one issue that I could notice was a potential data loss when you read incoming data into the `ByteBuffer` and then while transferring to a `DatagramPacket` can potentially transfer lesser than the read data if the `bufLength` of the `DatagramPacket` has changed. However as you already noted, this is an odd case and shouldn't ideally happen (although this current change does allow it to happen in theory, unlike previously). Plus I think the data loss case is already covered in the API documentation of `DatagramSocket.receive()` which states: > If the message is longer than the packet's length, the message is truncated. So I think this change is fine. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14901#pullrequestreview-1535063126 From jpai at openjdk.org Tue Jul 18 13:54:13 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 13:54:13 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman wrote: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. On a general note and more out of curiosity, I see that the `DatagramChannelImpl` dishonours the `blocking` mode set by the caller and forces non-blocking when virtual thread is involved and yet at the same time fulfills the contract of `receive()` and `send()` and even `isBlocking()`. Is there a reason we couldn't do the same for platform threads and dishonour the blocking mode and always use non-blocking in these `send()` and `receive()` implementations? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1640270637 From alanb at openjdk.org Tue Jul 18 14:06:02 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 14:06:02 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 13:50:51 GMT, Jaikiran Pai wrote: > On a general note and more out of curiosity, I see that the `DatagramChannelImpl` dishonours the `blocking` mode set by the caller and forces non-blocking when virtual thread is involved and yet at the same time fulfills the contract of `receive()` and `send()` and even `isBlocking()`. > > Is there a reason we couldn't do the same for platform threads and dishonour the blocking mode and always use non-blocking in these `send()` and `receive()` implementations? The blocking mode of the underlying socket is an implementation detail, it has no impact on the SocketChannel's blocking mode or the semantics of any of its methods. If a SocketChannel is in blocking mode and used exclusively by a platform thread then the underlying socket will be in blocking mode to avoid additional syscalls. If the underlying socket were non-blocking then it would require receive+poll+receive rather than a blocking-receive to wait for a datagram. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1640292027 From alanb at openjdk.org Tue Jul 18 14:11:10 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 14:11:10 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 13:38:12 GMT, Jaikiran Pai wrote: > The one issue that I could notice was a potential data loss when you read incoming data into the `ByteBuffer` and then while transferring to a `DatagramPacket` can potentially transfer lesser than the read data if the `bufLength` of the `DatagramPacket` has changed. Such code would be very broken. Even today, if code were to call setData to replace the byte[] while receive is blocked then it will do so once receive has completed. Any code that processes the datagram after receive may see the the new byte[] rather than the byte[] with the datagram. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1640301463 From jpai at openjdk.org Tue Jul 18 14:19:06 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Jul 2023 14:19:06 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 14:03:19 GMT, Alan Bateman wrote: > > On a general note and more out of curiosity, I see that the `DatagramChannelImpl` dishonours the `blocking` mode set by the caller and forces non-blocking when virtual thread is involved and yet at the same time fulfills the contract of `receive()` and `send()` and even `isBlocking()`. > > Is there a reason we couldn't do the same for platform threads and dishonour the blocking mode and always use non-blocking in these `send()` and `receive()` implementations? > > The blocking mode of the underlying socket is an implementation detail, it has no impact on the SocketChannel's blocking mode or the semantics of any of its methods. If a SocketChannel is in blocking mode and used exclusively by a platform thread then the underlying socket will be in blocking mode to avoid additional syscalls. If the underlying socket were non-blocking then it would require receive+poll+receive rather than a blocking-receive to wait for a datagram. Thank you Alan for the explanation. That helped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1640315153 From tsteele at openjdk.org Tue Jul 18 15:33:13 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 18 Jul 2023 15:33:13 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele wrote: > Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > >> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... > [emphasis added by me] > > By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. @bplb and @AlanBateman there's a bit more info in the JBS issue. I encourage you to take another look there too. > How many page sizes are you dealing with on AIX[?] Just two! > what does Unsafe::pageSize return vs. sysconf(_SC_PAGESIZE)[?] It boils down to [Dynamic Variable Page Sizes](https://www.ibm.com/docs/en/aix/7.2?topic=support-dynamic-variable-page-size), which is an AIX feature. The larger page size returned by Unsafe::pageSize is the system page size (by default 64 KiB). The page size required by msync (and returned by sysconf(_SC_PAGESIZE) is the fine-grained page size (by default 4 KiB). ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640454917 From tsteele at openjdk.org Tue Jul 18 15:38:16 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 18 Jul 2023 15:38:16 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 02:08:42 GMT, Brian Burkhalter wrote: >> Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. >> >>> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... >> [emphasis added by me] >> >> By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. > > src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 172: > >> 170: private static int pageSize() { >> 171: int ps = pageSize0(); >> 172: if (ps > 0) { > > If `sysconf(_SC_PAGESIZE)` returns a value different from `Bits::pageSize` on other Unix platforms, this could cause an unexpected change in behavior. Agreed. However, my thinking was that on systems with only one pagesize the size returned by sysconf is still the correct size to return. There is no need to pop back to the VM and trigger another call (to Bits.pageSize). > src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 175: > >> 173: return ps; >> 174: } else { >> 175: return Bits.pageSize(); > > `Bits::pageSize` returns `UnsafeConstants::PAGE_SIZE` which is injected by the VM. Could it be that that value is somehow derived differently on AIX? I believe so. See [the answer below](https://github.com/openjdk/jdk/pull/14904#issuecomment-1640454917) with regards to Dynamic Variable Page Sizes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266954998 PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266956602 From bpb at openjdk.org Tue Jul 18 15:39:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 18 Jul 2023 15:39:07 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 05:38:29 GMT, Vyom Tewari wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8136895: Remove vestigial explicit calls to close() in implClose() > > test/jdk/java/io/OutputStreamWriter/CloseWriterOnFailedFlush.java line 27: > >> 25: * @bug 8136895 >> 26: * @summary Verify stream closed after write error in StreamEncoder::implClose >> 27: */ > > Do you mind adding action tag(@run) ? [Ditto](https://openjdk.org/jtreg/tag-spec.html#DEFAULTS). > test/jdk/java/nio/channels/Channels/CloseWriterOnFailedFlush.java line 27: > >> 25: * @bug 8136895 >> 26: * @summary Verify channel closed after write error in StreamEncoder::implClose >> 27: */ > > Do you mind adding action tag(@run) ? Why? It is unnecessary. See [jtreg DEFAULTS](https://openjdk.org/jtreg/tag-spec.html#DEFAULTS). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13503#discussion_r1266958688 PR Review Comment: https://git.openjdk.org/jdk/pull/13503#discussion_r1266957991 From bpb at openjdk.org Tue Jul 18 15:42:13 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 18 Jul 2023 15:42:13 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 15:33:59 GMT, Tyler Steele wrote: >> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 172: >> >>> 170: private static int pageSize() { >>> 171: int ps = pageSize0(); >>> 172: if (ps > 0) { >> >> If `sysconf(_SC_PAGESIZE)` returns a value different from `Bits::pageSize` on other Unix platforms, this could cause an unexpected change in behavior. > > Agreed. However, my thinking was that on systems with only one pagesize the size returned by sysconf is still the correct size to return. There is no need to pop back to the VM and trigger another call (to Bits.pageSize). The risk is still non-zero. Calling `Bits::pageSize` does not pop back to the VM, it just returns the already injected constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1266964200 From stuefe at openjdk.org Tue Jul 18 15:56:03 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 18 Jul 2023 15:56:03 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> On Tue, 18 Jul 2023 15:30:23 GMT, Tyler Steele wrote: > > what does Unsafe::pageSize return vs. sysconf(_SC_PAGESIZE)[?] > > It boils down to [Dynamic Variable Page Sizes](https://www.ibm.com/docs/en/aix/7.2?topic=support-dynamic-variable-page-size), which is an AIX feature. The larger page size returned by Unsafe::pageSize is the system page size (by default 64 KiB). The page size required by msync (and returned by sysconf(_SC_PAGESIZE) is the fine-grained page size (by default 4 KiB). A bit of background: At the start of the JVM port to AIX (before OpenJDK) we wanted to use 64 KB pages, but the "LargePage" semantics used by the JVM were too rigid and too badly abstracted to be usable. So we instead "fake" a system page size of 64 KB instead of 4 KB by, basically, letting `os::vm_page_size()` return 64 KB. This works surprisingly well in most cases due to some peculiarities of AIX memory management. The real 4 KB system page size is only observable in a select few corner cases, one of which is this msync coding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640497243 From alanb at openjdk.org Tue Jul 18 16:08:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 16:08:14 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> References: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> Message-ID: On Tue, 18 Jul 2023 15:52:53 GMT, Thomas Stuefe wrote: > It boils down to [Dynamic Variable Page Sizes](https://www.ibm.com/docs/en/aix/7.2?topic=support-dynamic-variable-page-size), which is an AIX feature. The larger page size returned by Unsafe::pageSize is the system page size (by default 64 KiB). The page size required by msync (and returned by sysconf(_SC_PAGESIZE) is the fine-grained page size (by default 4 KiB). sysconf is usually documented to return values that don't change during the lifetime of the process. Does this AIX feature mean that sysconf(_SC_PAGESIZE) may initially return 4k but 64k some time later? If so, what does this mean for MappedByteBuffer.load/isLoaded/force and the equivalent methods on MemorySegment as they use the page size to compute the base address and offset. I see this bug report was because a MemorySegment test is failing but it hints that there may be long standing issues with MappedByteBuffer too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640517925 From alanb at openjdk.org Tue Jul 18 16:18:13 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 16:18:13 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> References: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> Message-ID: On Tue, 18 Jul 2023 15:52:53 GMT, Thomas Stuefe wrote: > A bit of background: At the start of the JVM port to AIX (before OpenJDK) we wanted to use 64 KB pages, but the "LargePage" semantics used by the JVM were too rigid and too badly abstracted to be usable. > > So we instead "fake" a system page size of 64 KB instead of 4 KB by, basically, letting `os::vm_page_size()` return 64 KB. This works surprisingly well in most cases due to some peculiarities of AIX memory management. The real 4 KB system page size is only observable in a select few corner cases, one of which is this msync coding. Does this mean that the injected value for Unsafe.PAGE_SIZE is 64k on AIX? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640535348 From vtewari at openjdk.org Tue Jul 18 16:33:13 2023 From: vtewari at openjdk.org (Vyom Tewari) Date: Tue, 18 Jul 2023 16:33:13 GMT Subject: RFR: 8136895: Writer not closed with disk full error, file resource leaked [v5] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 15:36:00 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/channels/Channels/CloseWriterOnFailedFlush.java line 27: >> >>> 25: * @bug 8136895 >>> 26: * @summary Verify channel closed after write error in StreamEncoder::implClose >>> 27: */ >> >> Do you mind adding action tag(@run) ? > > Why? It is unnecessary. See [jtreg DEFAULTS](https://openjdk.org/jtreg/tag-spec.html#DEFAULTS). thanks for link, i was not aware of jtreg defaults, looks like i have to update my very old Netbeans plugin it always complains about jtrg tag order etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13503#discussion_r1267028975 From stuefe at openjdk.org Tue Jul 18 16:37:14 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 18 Jul 2023 16:37:14 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> Message-ID: On Tue, 18 Jul 2023 16:15:30 GMT, Alan Bateman wrote: > > A bit of background: At the start of the JVM port to AIX (before OpenJDK) we wanted to use 64 KB pages, but the "LargePage" semantics used by the JVM were too rigid and too badly abstracted to be usable. > > So we instead "fake" a system page size of 64 KB instead of 4 KB by, basically, letting `os::vm_page_size()` return 64 KB. This works surprisingly well in most cases due to some peculiarities of AIX memory management. The real 4 KB system page size is only observable in a select few corner cases, one of which is this msync coding. > > Does this mean that the injected value for Unsafe.PAGE_SIZE is 64k on AIX? Yes :-( @backwaterred Try changing UnsafeConstant injection such that we inject the real system page size of 4K instead of using os::vm_page_size() here: https://github.com/openjdk/jdk/blob/b4dce0d62479c2494c02570a60319cb1a5932940/src/hotspot/share/classfile/javaClasses.cpp#L4710. Then, the JDK would see the real 4 KB whereas hotspot would continue to use 64 KB internally. Not sure how well that separation would work, but it may be worth a try. Mid- to long-term, we could think about reverting that decision and going back to real 4 KB. Essentially, rip out all coding in hotspot guarded by `-XX:+Use64KPages`. We would then see a performance drop because of the increased TLB usage. But maybe today's AIX machines are faster and can compensate for that. A future improvement could be adding real "hotspot-style" large page support using real 1 GB huge pages (which are supported on AIX but we never bothered). @AlanBateman As a defense of our old coding: We did this long before OpenJDK existed, and at that time, there was no way to contribute code back to Sun. Today I may do things differently. But back then, we had to aim for a minimally invasive patch, and this lying-about-pagesize worked well. There may be hidden issues like this we have not discovered yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640558149 From bpb at openjdk.org Tue Jul 18 16:46:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 18 Jul 2023 16:46:45 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v8] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Further refine specifications of varargs resolve methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/505d72b4..db4d9bd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=06-07 Stats: 43 lines in 1 file changed: 0 ins; 21 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From alanb at openjdk.org Tue Jul 18 17:01:11 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 17:01:11 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com> Message-ID: On Tue, 18 Jul 2023 16:15:30 GMT, Alan Bateman wrote: >>> > what does Unsafe::pageSize return vs. sysconf(_SC_PAGESIZE)[?] >>> >>> It boils down to [Dynamic Variable Page Sizes](https://www.ibm.com/docs/en/aix/7.2?topic=support-dynamic-variable-page-size), which is an AIX feature. The larger page size returned by Unsafe::pageSize is the system page size (by default 64 KiB). The page size required by msync (and returned by sysconf(_SC_PAGESIZE) is the fine-grained page size (by default 4 KiB). >> >> A bit of background: At the start of the JVM port to AIX (before OpenJDK) we wanted to use 64 KB pages, but the "LargePage" semantics used by the JVM were too rigid and too badly abstracted to be usable. >> >> So we instead "fake" a system page size of 64 KB instead of 4 KB by, basically, letting `os::vm_page_size()` return 64 KB. This works surprisingly well in most cases due to some peculiarities of AIX memory management. The real 4 KB system page size is only observable in a select few corner cases, one of which is this msync coding. > >> A bit of background: At the start of the JVM port to AIX (before OpenJDK) we wanted to use 64 KB pages, but the "LargePage" semantics used by the JVM were too rigid and too badly abstracted to be usable. >> >> So we instead "fake" a system page size of 64 KB instead of 4 KB by, basically, letting `os::vm_page_size()` return 64 KB. This works surprisingly well in most cases due to some peculiarities of AIX memory management. The real 4 KB system page size is only observable in a select few corner cases, one of which is this msync coding. > > Does this mean that the injected value for Unsafe.PAGE_SIZE is 64k on AIX? Should it be changed to the real page size? > @AlanBateman As a defense of our old coding: We did this long before OpenJDK existed, and at that time, there was no way to contribute code back to Sun. Today I may do things differently. But back then, we had to aim for a minimally invasive patch, and this lying-about-pagesize worked well. There may be hidden issues like this we have not discovered yet. No problem, it's good to get the history and get this issue to the right place. I was initially concerned we were into a scenario where the page size configuration could change and thus impact the base address and offset for operations like load and force. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14904#issuecomment-1640604743 From alanb at openjdk.org Tue Jul 18 17:18:14 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 18 Jul 2023 17:18:14 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v5] In-Reply-To: References: <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com> Message-ID: <_5LdkseM2iszSk0lwOrqwPaEs-B9xOm3zGCbjfjm-ro=.3a6e0b07-27eb-4d25-acf7-76b61d3246a8@github.com> On Mon, 17 Jul 2023 19:05:14 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 527: >> >>> 525: * {@code more} specifies one or more {@code Path}s, then each non-empty >>> 526: * {@code Path}, including {@code first}, is resolved iteratively against >>> 527: * this {@code Path}. >> >> The second paragraph has the same issue as before, it says "resolved iteratively against this Path" but that isn't correct. Same issue in the description of the "more" method. The first paragraph is correct, and I think we'll need to re-phrase the second paragraph to accurate specify how the iterative resolution works. > > 0fa126fd2d3861c56b85093e8a2483afa1ad9ef6 attempts to improve the aforementioned verbiage. > 0fa126f attempts to improve the aforementioned verbiage. The wording in the latest (db4d9bd6) looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1267081744 From alanb at openjdk.org Wed Jul 19 10:31:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 10:31:15 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v2] In-Reply-To: References: Message-ID: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Ensure SocketTimeoutException is thrown when SM set - Merge - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14901/files - new: https://git.openjdk.org/jdk/pull/14901/files/c5cebfd2..29337d6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14901&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14901&range=00-01 Stats: 5774 lines in 207 files changed: 4576 ins; 520 del; 678 mod Patch: https://git.openjdk.org/jdk/pull/14901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14901/head:pull/14901 PR: https://git.openjdk.org/jdk/pull/14901 From alanb at openjdk.org Wed Jul 19 10:31:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 10:31:33 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman wrote: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. One thing that I noticed is that the timeout handling when a legacy SecurityManager is set (and block datagrams) is that it interferes with the receive timeout. We don't seem to have a test for that so I've added a basic test to ensure that SocketTimeoutException is thrown when there is a SM set and it blocks all datagrams. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1641834463 From jpai at openjdk.org Wed Jul 19 11:31:44 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 11:31:44 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 10:31:15 GMT, Alan Bateman wrote: >> DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. >> >> DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. >> >> The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Ensure SocketTimeoutException is thrown when SM set > - Merge > - Merge > - Initial commit test/jdk/java/net/DatagramSocket/TimeoutWithSM.java line 63: > 61: System.out.println("checkAccept " + isa); > 62: if (isa.equals(sender)) { > 63: throw new SecurityException(); Given that the goal of this test is to exercise the case where the `SecurityManager` rejects incoming packets and then times out the receive call, would it be better to just throw `SecurityException` here for all host/port combinations instead of checking the sender? We have had cases, in the CI, where stray datagrams have been received in test cases from unexpected senders. In such cases this test will still fail, but with the assertion error that it received an unexpected packet . Throwing `SecurityException` for all addresses here, would avoid intermittent failures and in theory the test would then only get a `SocketTimeoutException`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14901#discussion_r1267941124 From jpai at openjdk.org Wed Jul 19 11:35:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 11:35:42 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 10:29:25 GMT, Alan Bateman wrote: > One thing that I noticed is that the timeout handling when a legacy SecurityManager is set (and block datagrams) is that it interferes with the receive timeout. That's a good catch. From what I can see, that bug has existed before the changes in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14901#issuecomment-1641917177 From michaelm at openjdk.org Wed Jul 19 11:41:43 2023 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 19 Jul 2023 11:41:43 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v2] In-Reply-To: References: Message-ID: <0ebo_TxjlNQUsgt2nIj10UelEOLqP8ssH8xmw7rk_gg=.d1405b8b-1262-4c98-9121-497cc07e4d4d@github.com> On Wed, 19 Jul 2023 10:31:15 GMT, Alan Bateman wrote: >> DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. >> >> DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. >> >> The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Ensure SocketTimeoutException is thrown when SM set > - Merge > - Merge > - Initial commit Latest version looks good to me. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14901#pullrequestreview-1536897916 From alanb at openjdk.org Wed Jul 19 12:16:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 12:16:43 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v2] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 11:29:21 GMT, Jaikiran Pai wrote: > Given that the goal of this test is to exercise the case where the `SecurityManager` rejects incoming packets and then times out the receive call, would it be better to just throw `SecurityException` here for all host/port combinations instead of checking the sender? checkAccess is called for other reasons too and the intention was just to drop datagrams from the sender. However, you may be right that there are other tests on the same host that are sending datagrams to random ports and could cause this test to fail if they happen to send it to the port that the test is using. So I'll re-test with that change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14901#discussion_r1267987200 From alanb at openjdk.org Wed Jul 19 12:38:31 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 12:38:31 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v3] In-Reply-To: References: Message-ID: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Make test more robust in the face of other tests sending to random ports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14901/files - new: https://git.openjdk.org/jdk/pull/14901/files/29337d6d..ced9cf3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14901&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14901&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14901/head:pull/14901 PR: https://git.openjdk.org/jdk/pull/14901 From jpai at openjdk.org Wed Jul 19 12:44:41 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Jul 2023 12:44:41 GMT Subject: RFR: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive [v3] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 12:38:31 GMT, Alan Bateman wrote: >> DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. >> >> DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. >> >> The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Make test more robust in the face of other tests sending to random ports Thank you for the update. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14901#pullrequestreview-1537004445 From alanb at openjdk.org Wed Jul 19 13:20:53 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Jul 2023 13:20:53 GMT Subject: Integrated: 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman wrote: > DatagramChannel is "virtual thread friendly"; when configured blocking, the receive/read methods release the carrier when there is no datagram to receive. > > DatagramChannel's socket adaptor (used by DatagramSocket) is not currently virtual thread friendly. The original changes proposed to address this in JDK 19 interacted with the carrier thread's buffer cache so we decided to not include them at the time. The change proposed here are to address this issue, mostly by moving the implementation of the socket adaptor's send/receive methods into the DatagramChannel implementation so that a temporary direct buffer is not held when parked. > > The only observable change should be to silly/broken code that changes a DatagramPacket's buffer (with setData or setLength) while a receive is in progress. Long standing, and undocumented, behavior would for setXXX to block while a receive is in progress, new behavior will be only access the DatagramPacket's buffer when a datagram is received. I can't think of anything that could rely on behavior like this. This pull request has now been integrated. Changeset: 028068a6 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/028068a655bb08e016e7a915c2b2f6abc1e480a0 Stats: 464 lines in 3 files changed: 269 ins; 141 del; 54 mod 8312166: (dc) DatagramChannel's socket adaptor does not release carrier thread when blocking in receive Reviewed-by: jpai, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/14901 From rriggs at openjdk.org Wed Jul 19 15:56:54 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 19 Jul 2023 15:56:54 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v8] In-Reply-To: References: Message-ID: On Tue, 18 Jul 2023 16:46:45 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Further refine specifications of varargs resolve methods test/jdk/java/nio/file/Path/PathOps.java line 195: > 193: others[i++] = Path.of(s); > 194: } > 195: check(path.resolve(Path.of(first), others), expected); This looks like it tests only the new method with Path elements. Are there tests for the new default method that accepts String. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1268283719 From tsteele at openjdk.org Wed Jul 19 19:05:28 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Wed, 19 Jul 2023 19:05:28 GMT Subject: RFR: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: <7uSfR3HQA1heK_Rf6OwL2jtruS-cU-OgrcfFJzQ6Vl0=.2da0e62d-13f1-4496-ab5e-5f2c51b33d56@github.com> On Tue, 18 Jul 2023 15:39:33 GMT, Brian Burkhalter wrote: > The risk is still non-zero. Fair point. I'll modify it to keep the same value a before, and only change AIX. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14904#discussion_r1268546481 From bpb at openjdk.org Thu Jul 20 03:55:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 20 Jul 2023 03:55:08 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v9] In-Reply-To: References: Message-ID: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8262742: Add coverage of resolve(String,String...) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14805/files - new: https://git.openjdk.org/jdk/pull/14805/files/db4d9bd6..c2a8faaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14805&range=07-08 Stats: 11 lines in 1 file changed: 8 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/14805.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14805/head:pull/14805 PR: https://git.openjdk.org/jdk/pull/14805 From bpb at openjdk.org Thu Jul 20 03:55:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 20 Jul 2023 03:55:08 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v8] In-Reply-To: References: Message-ID: On Wed, 19 Jul 2023 15:54:23 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8262742: Further refine specifications of varargs resolve methods > > test/jdk/java/nio/file/Path/PathOps.java line 195: > >> 193: others[i++] = Path.of(s); >> 194: } >> 195: check(path.resolve(Path.of(first), others), expected); > > This looks like it tests only the new method with Path elements. > Are there tests for the new default method that accepts String. Addressed in c2a8faaa1b81dbb40e1a5989a02c9e5935417358. Thanks for pointing it out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1268901624 From bpb at openjdk.org Thu Jul 20 03:55:08 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 20 Jul 2023 03:55:08 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v2] In-Reply-To: References: <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com> Message-ID: On Mon, 17 Jul 2023 21:16:37 GMT, Brian Burkhalter wrote: >> Multiple directories would be good but I don't know about `..`. > >> Should there be test cases that include multiple directories in a path: "abc/def/xyz"? > > Added some multiple directory cases in 505d72b48c5d34bbf4474c6fed43e2f269e8e135. > >> Also cases with ".." > > This is not relevant. For example, using the existing `resolve(Path)`: > > > jshell> java.nio.file.Path.of("/tmp").resolve("..").resolve("..") > $1 ==> /tmp/../.. Addressed in c2a8faaa1b81dbb40e1a5989a02c9e5935417358. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14805#discussion_r1268901442 From alanb at openjdk.org Thu Jul 20 06:47:40 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 20 Jul 2023 06:47:40 GMT Subject: RFR: JDK-8310734: Add cause to Connection reset - SocketException in NioSocketImpl implRead In-Reply-To: References: Message-ID: <5UrSUIO1UhgQ1YY5U3ZcHu26sZakj8aHyknrRVEfJaQ=.2004671f-6620-4daa-9d49-560b3b3337cc@github.com> On Fri, 30 Jun 2023 14:13:10 GMT, Matthias Baesken wrote: > In NioSocketImpl implRead we potentially throw a SocketException("Connection reset"). We can improve this by adding the cause. > This would bring this exception also closer to the case of IOException where we use throw asSocketException(ioe); and preserve the stack and message of the original exception. Can this PR be closed? In the JBS issue I think we agreed that this shouldn't be used as the cause here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14734#issuecomment-1643361365 From mbaesken at openjdk.org Thu Jul 20 07:06:49 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Jul 2023 07:06:49 GMT Subject: RFR: JDK-8310734: Add cause to Connection reset - SocketException in NioSocketImpl implRead In-Reply-To: <5UrSUIO1UhgQ1YY5U3ZcHu26sZakj8aHyknrRVEfJaQ=.2004671f-6620-4daa-9d49-560b3b3337cc@github.com> References: <5UrSUIO1UhgQ1YY5U3ZcHu26sZakj8aHyknrRVEfJaQ=.2004671f-6620-4daa-9d49-560b3b3337cc@github.com> Message-ID: On Thu, 20 Jul 2023 06:44:46 GMT, Alan Bateman wrote: > Can this PR be closed? In the JBS issue I think we agreed that this shouldn't be used as the cause here. Hi Alan, yes I think so . ------------- PR Comment: https://git.openjdk.org/jdk/pull/14734#issuecomment-1643389539 From mbaesken at openjdk.org Thu Jul 20 07:06:51 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Jul 2023 07:06:51 GMT Subject: Withdrawn: JDK-8310734: Add cause to Connection reset - SocketException in NioSocketImpl implRead In-Reply-To: References: Message-ID: <3cMCHhxiRvGJZVCiAuf4hJmBmS48D1u8di-WaloNNrk=.94cf2661-00c9-4ffd-80e2-c8ba27b12655@github.com> On Fri, 30 Jun 2023 14:13:10 GMT, Matthias Baesken wrote: > In NioSocketImpl implRead we potentially throw a SocketException("Connection reset"). We can improve this by adding the cause. > This would bring this exception also closer to the case of IOException where we use throw asSocketException(ioe); and preserve the stack and message of the original exception. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14734 From mkartashev at openjdk.org Thu Jul 20 09:16:20 2023 From: mkartashev at openjdk.org (Maxim Kartashev) Date: Thu, 20 Jul 2023 09:16:20 GMT Subject: RFR: 8293067: (fs) Implement WatchService using system library (macOS) [v11] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 10:47:16 GMT, Maxim Kartashev wrote: >> This is an implementation of `WatchService` based on File System Events API that is capable of generating events whenever a change occurs in an interesting directory or underneath it. Since the API naturally supports "recursive" watch, the `FILE_TREE` is supported by the watch service. >> >> Some things of note: >> * There's one "service" thread per `WatchService` instance that is inactive unless changes occur in the watched directory. The changes are grouped by introducing a time delay between when they occurred and when they are reported, which is controlled by the sensitivity modifier of the watch service. >> * Since FSEvents API reports directories only, the watch service keeps a snapshot (hierarchical if necessary) of the files in the directory being watched. The snapshot gets updated when an event in that directory or underneath it gets delivered. File changes are detected by comparing "last modified" time with a millisecond precision (`BasicFileAttributes.lastModifiedTime()`). >> * There is a slight complication with the move of an entire directory hierarchy: FSEvents API only reports about the containing directory of that move and not about any of the directories actually moved. There's a separate test for that (`Move.java`). >> * The code is careful not to do any I/O (such as reading the contents of a directory or attributes of a file) unless unavoidable. Any deviation from this line should be considered a bug (of, arguably, low priority). >> * The native part consists mostly of API wrappers with one exception of the callback function invoked by the system to report the events that occurred. The sole task of the function is to convert from C strings to Java strings and pass the array of affected directories to Java code. This can be rewritten if desired to make the code more future-proof. >> >> This commit leaves `PollingWatchService` unused. I'm not sure if I should/can do anything about it. Any advice is welcomed. >> >> ### Testing >> >> * Tested by running `test/jdk/java/nio/file` and `test/jdk/jdk/nio` on MacOS 10.15.7 (x64) and `test/jdk/java/nio/` plus `test/jdk/jdk/nio` on MacOS 12.5.1 (aarch64). >> * Also verified that new tests pass on Linux and Windows. >> * This code (albeit in a slightly modified form) has been in use at JetBrains for around half a year and a few bugs have been found and fixed during that time period. > > Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision: > > Check FSEventStreamStart() return value For the record: I finally got around to trying the new dispatch queues API. This reduces the complexity of the current implementation quite a bit and passes all tests except one. The obstacle I have not been able to overcome is this: the new implementation consistently fails the test `test/jdk/java/nio/file/WatchService/LotsOfCancels.java`, which creates many watch services and constantly starts/stops FSEventStream's. I have not been able to find any solution to this; perhaps we are hitting some OS resource limit, even though not that many streams are active at any given moment (sometimes you can also see the "too many open files" exception from that test when it creates new temporary files). So far it loos like this new API is no go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10140#issuecomment-1643564943 From bpb at openjdk.org Thu Jul 20 18:17:51 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 20 Jul 2023 18:17:51 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec Message-ID: Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. ------------- Commit messages: - 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec Changes: https://git.openjdk.org/jdk/pull/14961/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14961&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4800398 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14961/head:pull/14961 PR: https://git.openjdk.org/jdk/pull/14961 From tsteele at openjdk.org Thu Jul 20 20:47:52 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 20 Jul 2023 20:47:52 GMT Subject: Withdrawn: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 23:20:10 GMT, Tyler Steele wrote: > Solves the issue by searching `/proc//map` for the map after an EINVAL. If the map is marked `MAP_PRIVATE` then EINVAL is ignored. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14914 From tsteele at openjdk.org Thu Jul 20 22:44:50 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Thu, 20 Jul 2023 22:44:50 GMT Subject: Withdrawn: 8312180: (bf) MappedMemoryUtils passes incorrect arguments to msync (aix) In-Reply-To: References: Message-ID: On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele wrote: > Calls to `msync` on AIX require the length to be a multiple of a specific pagesize which may not be the same as the one returned by `Bits.pageSize()`, as explained in the JBS issue description. > >> EINVAL The addr argument is not a multiple of the page size as **returned by the sysconf subroutine using the _SC_PAGE_SIZE value for the Name parameter**, ... > [emphasis added by me] > > By adding this as platform dependant code, the correct value of page size is used on AIX. Other Unix platforms should see no change by calling sysconf instead of Bits.pagesize. Windows is unchanged. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14904 From alanb at openjdk.org Fri Jul 21 06:34:39 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Jul 2023 06:34:39 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 18:11:15 GMT, Brian Burkhalter wrote: > Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. src/java.base/share/classes/java/nio/channels/Channels.java line 264: > 262: *

        The resulting channel will be in blocking mode and will not be > 263: * buffered; it will simply redirect its I/O operations to the given stream. > 264: * Closing the channel will in turn cause the stream to be closed.

        ReadableByteChannel doesn't have any notion of blocking mode so might be confusing to say that it returns a channel in blocking mode. Maybe it would be simpler to just insert a sentence into the paragraph to say that reading from the resulting channel will read (and therefore might blocking reading) from the input stream? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14961#discussion_r1270275577 From bpb at openjdk.org Fri Jul 21 15:23:54 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 21 Jul 2023 15:23:54 GMT Subject: Integrated: 8136895: Writer not closed with disk full error, file resource leaked In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 02:03:19 GMT, Brian Burkhalter wrote: > In`StreamEncoder::implClose`, move `flushLeftoverChar()` inside the `try` block and the closing of the underlying stream inside the `finally` block. This pull request has now been integrated. Changeset: d55d7e8d Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/d55d7e8d87670043dd22ec6a3fb6cc49b39000cd Stats: 200 lines in 4 files changed: 183 ins; 10 del; 7 mod 8136895: Writer not closed with disk full error, file resource leaked Reviewed-by: djelinski, vtewari ------------- PR: https://git.openjdk.org/jdk/pull/13503 From bpb at openjdk.org Fri Jul 21 15:43:07 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 21 Jul 2023 15:43:07 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v2] In-Reply-To: References: Message-ID: > Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4800398: Revise verbiage update per Reviewer suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14961/files - new: https://git.openjdk.org/jdk/pull/14961/files/e494e780..dba2d334 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14961&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14961&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/14961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14961/head:pull/14961 PR: https://git.openjdk.org/jdk/pull/14961 From bpb at openjdk.org Fri Jul 21 15:44:45 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 21 Jul 2023 15:44:45 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 06:32:10 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4800398: Revise verbiage update per Reviewer suggestion > > src/java.base/share/classes/java/nio/channels/Channels.java line 264: > >> 262: *

        The resulting channel will be in blocking mode and will not be >> 263: * buffered; it will simply redirect its I/O operations to the given stream. >> 264: * Closing the channel will in turn cause the stream to be closed.

        > > ReadableByteChannel doesn't have any notion of blocking mode so might be confusing to say that it returns a channel in blocking mode. Maybe it would be simpler to just insert a sentence into the paragraph to say that reading from the resulting channel will read (and therefore might block reading) from the input stream? Changed as suggested in dba2d33. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14961#discussion_r1270824218 From alanb at openjdk.org Fri Jul 21 16:29:41 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Jul 2023 16:29:41 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 15:43:07 GMT, Brian Burkhalter wrote: >> Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4800398: Revise verbiage update per Reviewer suggestion src/java.base/share/classes/java/nio/channels/Channels.java line 264: > 262: *

        The resulting channel will not be buffered; it will simply redirect > 263: * its I/O operations to the given stream. Reading from the resulting > 264: * channel will read from the input stream hence might block. Closing the A suggestion is to replace "will read from the input stream hence might block" with "will read from the input stream and thus block until input is available or end of file is reached", would that work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14961#discussion_r1270865805 From bpb at openjdk.org Fri Jul 21 16:29:41 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 21 Jul 2023 16:29:41 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v2] In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 16:25:37 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4800398: Revise verbiage update per Reviewer suggestion > > src/java.base/share/classes/java/nio/channels/Channels.java line 264: > >> 262: *

        The resulting channel will not be buffered; it will simply redirect >> 263: * its I/O operations to the given stream. Reading from the resulting >> 264: * channel will read from the input stream hence might block. Closing the > > A suggestion is to replace "will read from the input stream hence might block" with "will read from the input stream and thus block until input is available or end of file is reached", would that work? That is indeed more specific. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14961#discussion_r1270866801 From bpb at openjdk.org Fri Jul 21 16:35:55 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 21 Jul 2023 16:35:55 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v3] In-Reply-To: References: Message-ID: > Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4800398: Revise verbiage update per Reviewer suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14961/files - new: https://git.openjdk.org/jdk/pull/14961/files/dba2d334..4a64cf25 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14961&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14961&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/14961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14961/head:pull/14961 PR: https://git.openjdk.org/jdk/pull/14961 From alanb at openjdk.org Fri Jul 21 16:38:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Jul 2023 16:38:42 GMT Subject: RFR: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec [v3] In-Reply-To: References: Message-ID: <8zlYcbVMbVR37j-BzUTI5JQ9deXSRAm32Ka001hvztA=.963f90f3-b5a5-4d8b-a870-412f52e24319@github.com> On Fri, 21 Jul 2023 16:35:55 GMT, Brian Burkhalter wrote: >> Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4800398: Revise verbiage update per Reviewer suggestion Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14961#pullrequestreview-1541483954 From alanb at openjdk.org Sat Jul 22 10:01:44 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 22 Jul 2023 10:01:44 GMT Subject: RFR: 8262742: (fs) Add Path::resolve with varargs string [v9] In-Reply-To: References: Message-ID: <0R5tmTCqwAkc0ndvTF9DCRzH53bUfEj_foHy8KH3VoI=.46cb813f-a819-45ba-ab95-77a6ecd0f151@github.com> On Thu, 20 Jul 2023 03:55:08 GMT, Brian Burkhalter wrote: >> Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8262742: Add coverage of resolve(String,String...) Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/14805#pullrequestreview-1542076671 From bpb at openjdk.org Mon Jul 24 20:02:56 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 24 Jul 2023 20:02:56 GMT Subject: Integrated: 8262742: (fs) Add Path::resolve with varargs string In-Reply-To: References: Message-ID: <8rdYmFhfDxFWQJPn2G5id0O7tmSwjkxMLrr3yGjAnjY=.666a7c07-4068-491b-891f-e74285ec1ffe@github.com> On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter wrote: > Add to `java.nio.file.Path` methods which allow resolution of multiple descendants. This pull request has now been integrated. Changeset: 2bdfa836 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/2bdfa836adbeba3319bee4ee61017907d6d84d58 Stats: 239 lines in 3 files changed: 237 ins; 0 del; 2 mod 8262742: (fs) Add Path::resolve with varargs string Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14805 From tsteele at openjdk.org Tue Jul 25 14:30:11 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 25 Jul 2023 14:30:11 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) Message-ID: This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. > In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] Separated into separate file as per recommendation by @AlanBateman. [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() ------------- Depends on: https://git.openjdk.org/jdk/pull/14963 Commit messages: - Maintain linux-specific definition for minicore_vec_t - Separate AIX MappedMemoryUtils to new file. Add force0 implementation - Replace vm_page_size call with sysconf(_SC_PAGESIZE) in javaClasses.cpp Changes: https://git.openjdk.org/jdk/pull/14964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309475 Stats: 233 lines in 2 files changed: 210 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14964/head:pull/14964 PR: https://git.openjdk.org/jdk/pull/14964 From alanb at openjdk.org Wed Jul 26 07:45:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 26 Jul 2023 07:45:52 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: References: Message-ID: <-WEGyH-071rq9h_uuEeCHN1ZzwnDTptJqRI4jbaEHz8=.53f7e893-f6b9-46d7-862b-512e7e3413f5@github.com> On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele wrote: > This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. > >> In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] > > Separated into separate file as per recommendation by @AlanBateman. > > [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() It's good that this doesn't clutter the Unix implementation of these methods with a lot of AIX-specific code. However, part of me wonders if force should special case the read-only or private mapping cases so that it's just a no-op, need to think about that one as the MBB implementation doesn't know if the mapping is read-write or private. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14964#issuecomment-1651152630 From tsteele at openjdk.org Wed Jul 26 15:04:48 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Wed, 26 Jul 2023 15:04:48 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: <-WEGyH-071rq9h_uuEeCHN1ZzwnDTptJqRI4jbaEHz8=.53f7e893-f6b9-46d7-862b-512e7e3413f5@github.com> References: <-WEGyH-071rq9h_uuEeCHN1ZzwnDTptJqRI4jbaEHz8=.53f7e893-f6b9-46d7-862b-512e7e3413f5@github.com> Message-ID: On Wed, 26 Jul 2023 07:42:50 GMT, Alan Bateman wrote: > part of me wonders if force should special case the read-only or private mapping cases so that it's just a no-op, need to think about that one as the MBB implementation doesn't know if the mapping is read-write or private. I agree with the sentiment. It would be nice to have this information available without so much heavy lifting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14964#issuecomment-1651991057 From bpb at openjdk.org Wed Jul 26 15:10:49 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 26 Jul 2023 15:10:49 GMT Subject: Integrated: 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 18:11:15 GMT, Brian Burkhalter wrote: > Clarify that the `ReadableByteChannel` returned by `Channels::newChannel` is in blocking mode. This pull request has now been integrated. Changeset: 74121930 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/74121930e33686d2452170554776c0901f622d3e Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 4800398: (ch spec) Clarify Channels.newChannel(InputStream) spec Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/14961 From duke at openjdk.org Thu Jul 27 14:49:43 2023 From: duke at openjdk.org (Thomas Obermeier) Date: Thu, 27 Jul 2023 14:49:43 GMT Subject: RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX Message-ID: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. ------------- Commit messages: - Update ProblemList.txt exclude java/foreign/TestByteBuffer Changes: https://git.openjdk.org/jdk/pull/15055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313250 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15055/head:pull/15055 PR: https://git.openjdk.org/jdk/pull/15055 From rriggs at openjdk.org Thu Jul 27 14:53:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 27 Jul 2023 14:53:51 GMT Subject: RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> Message-ID: On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier wrote: > exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/15055#pullrequestreview-1550061225 From clanger at openjdk.org Thu Jul 27 15:11:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 15:11:49 GMT Subject: RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> Message-ID: On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier wrote: > exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. Looks good and trivial ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15055#pullrequestreview-1550099334 From clanger at openjdk.org Thu Jul 27 15:13:53 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 15:13:53 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele wrote: > This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. > >> In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] > > Separated into separate file as per recommendation by @AlanBateman. > > [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() FYI: We are excluding the failing test for the time being in #15055. The exclusion will need to be removed with the final commit for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14964#issuecomment-1653821589 From duke at openjdk.org Thu Jul 27 15:48:59 2023 From: duke at openjdk.org (Thomas Obermeier) Date: Thu, 27 Jul 2023 15:48:59 GMT Subject: Integrated: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> Message-ID: On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier wrote: > exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. This pull request has now been integrated. Changeset: c05ba48b Author: Thomas Obermeier <128162199+TOatGithub at users.noreply.github.com> Committer: Christoph Langer URL: https://git.openjdk.org/jdk/commit/c05ba48b60816db0165a6d3ff534fbbb18433cd4 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8313250: Exclude java/foreign/TestByteBuffer.java on AIX Reviewed-by: rriggs, clanger ------------- PR: https://git.openjdk.org/jdk/pull/15055 From clanger at openjdk.org Thu Jul 27 16:17:01 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 16:17:01 GMT Subject: [jdk21] RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX Message-ID: Hi all, This pull request contains a backport of [JDK-8313250](https://bugs.openjdk.org/browse/JDK-8313250), commit [c05ba48b](https://github.com/openjdk/jdk/commit/c05ba48b60816db0165a6d3ff534fbbb18433cd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. It's only a test exclusion for AIX, suitable for RDP2. Thanks! ------------- Commit messages: - Backport c05ba48b60816db0165a6d3ff534fbbb18433cd4 Changes: https://git.openjdk.org/jdk21/pull/148/files Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=148&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313250 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk21/pull/148.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/148/head:pull/148 PR: https://git.openjdk.org/jdk21/pull/148 From rriggs at openjdk.org Thu Jul 27 18:42:46 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 27 Jul 2023 18:42:46 GMT Subject: [jdk21] RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 15:58:22 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8313250](https://bugs.openjdk.org/browse/JDK-8313250), commit [c05ba48b](https://github.com/openjdk/jdk/commit/c05ba48b60816db0165a6d3ff534fbbb18433cd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It's only a test exclusion for AIX, suitable for RDP2. > > Thanks! Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk21/pull/148#pullrequestreview-1550527905 From clanger at openjdk.org Thu Jul 27 21:44:58 2023 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 27 Jul 2023 21:44:58 GMT Subject: [jdk21] Integrated: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: References: Message-ID: <0p9J5GP1xu1aAEJU1aFEeVEZ6Xbfie_lf1tZPIDExGg=.2ab59ea6-1e0b-42e3-a244-6931376c9e2a@github.com> On Thu, 27 Jul 2023 15:58:22 GMT, Christoph Langer wrote: > Hi all, > > This pull request contains a backport of [JDK-8313250](https://bugs.openjdk.org/browse/JDK-8313250), commit [c05ba48b](https://github.com/openjdk/jdk/commit/c05ba48b60816db0165a6d3ff534fbbb18433cd4) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It's only a test exclusion for AIX, suitable for RDP2. > > Thanks! This pull request has now been integrated. Changeset: 1c875fd4 Author: Christoph Langer URL: https://git.openjdk.org/jdk21/commit/1c875fd49941c940fb3a770a6540889cabf427cf Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8313250: Exclude java/foreign/TestByteBuffer.java on AIX Reviewed-by: rriggs Backport-of: c05ba48b60816db0165a6d3ff534fbbb18433cd4 ------------- PR: https://git.openjdk.org/jdk21/pull/148 From alanb at openjdk.org Fri Jul 28 09:58:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 28 Jul 2023 09:58:56 GMT Subject: RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> Message-ID: On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier wrote: > exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. test/jdk/ProblemList.txt line 792: > 790: > 791: ############################################################################ > 792: # java/foreign The convention used in the comments on each section is to use the group name rather than the package name, in this case, it's jdk_foreign. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15055#discussion_r1277353837 From clanger at openjdk.org Fri Jul 28 11:33:49 2023 From: clanger at openjdk.org (Christoph Langer) Date: Fri, 28 Jul 2023 11:33:49 GMT Subject: RFR: 8313250: Exclude java/foreign/TestByteBuffer.java on AIX In-Reply-To: References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com> Message-ID: <3SSXLPc3H2EXrlL8nOug5MVwi0W5NIOIjUq6P3OvUVQ=.56222a29-4a4d-445d-b3cf-43f2ffc87ae4@github.com> On Fri, 28 Jul 2023 09:56:10 GMT, Alan Bateman wrote: >> exclude java/foreign/TestByteBuffer on AIX until https://bugs.openjdk.org/browse/JDK-8309475 is fixed. > > test/jdk/ProblemList.txt line 792: > >> 790: >> 791: ############################################################################ >> 792: # java/foreign > > The convention used in the comments on each section is to use the group name rather than the package name, in this case, it's jdk_foreign. OK, we'll fix this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15055#discussion_r1277432964 From bpb at openjdk.org Mon Jul 31 18:24:00 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 31 Jul 2023 18:24:00 GMT Subject: RFR: 8313368: (fc) FileChannel.size returns 0 on block special files Message-ID: Reinstate header files so that `BLKGETSIZE64` is defined on Linux. ------------- Commit messages: - 8313368: (fc) FileChannel.size returns 0 on block special files Changes: https://git.openjdk.org/jdk/pull/15092/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313368 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15092/head:pull/15092 PR: https://git.openjdk.org/jdk/pull/15092 From bpb at openjdk.org Mon Jul 31 18:24:01 2023 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 31 Jul 2023 18:24:01 GMT Subject: RFR: 8313368: (fc) FileChannel.size returns 0 on block special files In-Reply-To: References: Message-ID: <_lU82KgsqDOTsZTJeO7f9g0K6YtCEFinUaxsk68pTyM=.9c7642e5-55d3-4929-b335-472230bbff8b@github.com> On Mon, 31 Jul 2023 18:16:49 GMT, Brian Burkhalter wrote: > Reinstate header files so that `BLKGETSIZE64` is defined on Linux. The proposed fix was verified manually using the test attached to the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15092#issuecomment-1658916203 From alanb at openjdk.org Mon Jul 31 19:13:53 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 31 Jul 2023 19:13:53 GMT Subject: RFR: 8313368: (fc) FileChannel.size returns 0 on block special files In-Reply-To: References: Message-ID: On Mon, 31 Jul 2023 18:16:49 GMT, Brian Burkhalter wrote: > Reinstate header files so that `BLKGETSIZE64` is defined on Linux. src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 52: > 50: #include > 51: #endif > 52: This looks okay, I just wonder if the `#ifdef BLKGETSIZE64` could be replaced with `#ifdef __linux__` to avoid accidents when the set of include files changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15092#discussion_r1279758797 From tsteele at openjdk.org Mon Jul 31 21:31:51 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 31 Jul 2023 21:31:51 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: References: Message-ID: On Thu, 27 Jul 2023 15:10:31 GMT, Christoph Langer wrote: >> This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. >> >>> In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] >> >> Separated into separate file as per recommendation by @AlanBateman. >> >> [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() > > FYI: We are excluding the failing test for the time being in #15055. The exclusion will need to be removed with the final commit for this. Thanks for mentioning it @RealCLanger. I'll remove the exception from the ProblemList before I merge. This PR and #14963 are ready for reviews if anyone has a chance to take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14964#issuecomment-1659187510 From tsteele at openjdk.org Mon Jul 31 21:52:25 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 31 Jul 2023 21:52:25 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) [v2] In-Reply-To: References: Message-ID: > This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. > >> In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] > > Separated into separate file as per recommendation by @AlanBateman. > > [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Re-Removes problem list entry - Maintain linux-specific definition for minicore_vec_t - Separate AIX MappedMemoryUtils to new file. Add force0 implementation - Replace vm_page_size call with sysconf(_SC_PAGESIZE) in javaClasses.cpp ------------- Changes: https://git.openjdk.org/jdk/pull/14964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14964&range=01 Stats: 238 lines in 3 files changed: 210 ins; 28 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/14964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14964/head:pull/14964 PR: https://git.openjdk.org/jdk/pull/14964 From tsteele at openjdk.org Mon Jul 31 21:52:26 2023 From: tsteele at openjdk.org (Tyler Steele) Date: Mon, 31 Jul 2023 21:52:26 GMT Subject: RFR: 8309475: Test java/foreign/TestByteBuffer.java fails: a problem with msync (aix) In-Reply-To: References: Message-ID: On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele wrote: > This change adds additional support to MappedByteBuffer::force which delegates to msync on AIX. Specifically, it checks whether and error with errno set to EINVAL is the cause of a msync call to an address mmapped with the MAP_PRIVATE flag set. If this flag is set, then the msync call EINVAL is expected, and can be ignored as per the Java documentation of the force method. > >> In particular, the method has no effect for buffers mapped in read-only or private mapping modes. [1] > > Separated into separate file as per recommendation by @AlanBateman. > > [1] https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/nio/MappedByteBuffer.html#force() Fixing chaos brought on by merging with upstream/master branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14964#issuecomment-1659226676