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: <LqAr1GACsVMRcLs__YwYacxX4nWB1Mvdj53Sd_T9SEg=.970981c7-0b4b-4b55-be69-fa553a5d2db6@github.com>
 <41KzLmzQ0OvgW2krFTfq1HpzJr2L3_RsqltCVbWewhE=.a1e94e0d-774c-49be-ad16-f544f44d0bb7@github.com>
Message-ID: <i1H7jGIep2G-5Vm6qyTueWHmCQbbkR3rKU6EE2pSKJ8=.ec20ccc6-55df-4d8f-826d-17b55b873780@github.com>

On Sun, 9 Apr 2023 13:43:36 GMT, Markus KARG <duke at openjdk.org> 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: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <R8ahjexrLcvRbR6n70YCDpumO9JLciTtQVMerSBeF7A=.74722922-81d0-4540-9368-f8baec231d4b@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> 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: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <QL1mu3tMUJKOVgFNb03imzSoky1Gk6bnGaQSQDBpHcE=.95e04215-5022-43bc-97a3-ff717657e5fa@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> 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: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
References: <NAPbyNGRsUaPheW2vp9H21mj9ZxhVVXhn-yHfBTCQWs=.91b0d6ce-6da4-441e-8464-fac7a9095291@github.com>
Message-ID: <7t1XdHgfOIvk0W4hzJ-0ppHjR2W2DKUwKSK-3P7E3Yw=.32776839-6368-4556-9ee0-60a14d31e458@github.com>

On Mon, 3 Jul 2023 17:02:58 GMT, Naoto Sato <naoto at openjdk.org> 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 <naoto at openjdk.org>
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: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
References: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
Message-ID: <llzgIkXYsP8hms8a-auZ-rWRUsRkPkb4vU7E-D4VSj8=.f24ca796-ffc0-4a41-a03a-a045b535a200@github.com>

On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato <naoto at openjdk.org> 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: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
References: <wdMK-hzifuGIftCFfx1DpTFASh8D01f9EWkSYhBilUw=.cb1448f3-6592-427f-a169-b74fe56e50cc@github.com>
Message-ID: <mXOUrhkSigZ3545P9mvqlNBf-rFPL3yQ3zhTWbi4F-A=.7b022895-381f-4f58-9924-665b84cb975d@github.com>

On Thu, 6 Jul 2023 00:30:14 GMT, Naoto Sato <naoto at openjdk.org> 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 <naoto at openjdk.org>
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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>

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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <S7N3zmGe1yzmHAc9TKDgmzIukrCot97kO7pR7w6Vk2c=.bf7cfa23-921b-4d79-b69f-ebd500184684@github.com>

On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>

On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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:      * <p> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com>

On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com>
Message-ID: <pmfpG7aGy-ZGY5wfNmWwc0OYqtHhx0iONK2rZ8AkzYA=.ddfbdf79-7d71-43de-822d-2955f16b5003@github.com>

On Sat, 8 Jul 2023 10:34:44 GMT, ExE Boss <duke at openjdk.org> 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: <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>
Message-ID: <ZjZNzvqQ44MS1YeJZfpb3WUY3ioJBdv1XIZIb4VvZtA=.2febcdb5-e9d9-43c9-9c0f-c7fb91b29696@github.com>

On Sat, 8 Jul 2023 05:55:08 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <ZjZNzvqQ44MS1YeJZfpb3WUY3ioJBdv1XIZIb4VvZtA=.2febcdb5-e9d9-43c9-9c0f-c7fb91b29696@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>
 <ZjZNzvqQ44MS1YeJZfpb3WUY3ioJBdv1XIZIb4VvZtA=.2febcdb5-e9d9-43c9-9c0f-c7fb91b29696@github.com>
Message-ID: <EsD38s_eKcF0LY8PhBuEFIHKru_rpOGRHPbPU1tw0Ck=.fd160498-17d0-4968-879d-4d243c235b52@github.com>

On Mon, 10 Jul 2023 06:15:29 GMT, Alan Bateman <alanb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
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: <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <Lhx9lWHWrxtzM9R6C4QJQ8wEoFdhY8_WBjHPz_QRyrA=.269d5e06-15de-4be8-8be6-d6348fe69217@github.com>
Message-ID: <ZpoWioh6wViAyjAvY8PzE_cIg97NFymcgdnazHXMyVo=.18f352bb-de17-4a7e-b0ef-8e4ae3ace7a0@github.com>

On Sat, 8 Jul 2023 05:56:40 GMT, Jaikiran Pai <jpai at openjdk.org> 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:      * <p> 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:      * <p> 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: <pmfpG7aGy-ZGY5wfNmWwc0OYqtHhx0iONK2rZ8AkzYA=.ddfbdf79-7d71-43de-822d-2955f16b5003@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <77kaqTCsmaEn5c4u3V6gRfvA0yrjip1oNRPn7Sd8w-s=.ebc31c54-93f1-4f3e-adca-8ba013f42699@github.com>
 <pmfpG7aGy-ZGY5wfNmWwc0OYqtHhx0iONK2rZ8AkzYA=.ddfbdf79-7d71-43de-822d-2955f16b5003@github.com>
Message-ID: <6b5OjBVBrS79n5MEfYB4c1W6htuBqkhmu7eqOggmTdk=.d117ffc1-0ba7-4274-ac23-3157e72d0cca@github.com>

On Sat, 8 Jul 2023 12:49:51 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <tlKqG_Emo0_WJNqtDsVJN2lJ-tLXvjXrkatTgC5LYm0=.4f17b893-d009-4d51-abca-bfe3d4338427@github.com>
References: <tlKqG_Emo0_WJNqtDsVJN2lJ-tLXvjXrkatTgC5LYm0=.4f17b893-d009-4d51-abca-bfe3d4338427@github.com>
Message-ID: <E0Fdmx6fPQxn36bg2eRJurrxUhgeskD-NP2S9guVtgg=.bb5e92bf-d81a-46eb-8718-59ceda6b3abf@github.com>

On Wed, 21 Jun 2023 17:24:19 GMT, Naoto Sato <naoto at openjdk.org> 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 <naoto at openjdk.org>
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: <OWzenp1llVs0ccA83tYstwBwPHY6X67t_75_TUyBctk=.c27fbe65-0c06-46a8-84ec-52e69c7ee3de@github.com>
References: <OWzenp1llVs0ccA83tYstwBwPHY6X67t_75_TUyBctk=.c27fbe65-0c06-46a8-84ec-52e69c7ee3de@github.com>
Message-ID: <dDKXTPq8FVTAfryn310nk9-5IJEehjuU_fGzEDjz-U8=.e6fe6cf1-9acb-4a9c-9bea-e90c5b725f6e@github.com>

> 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: <OWzenp1llVs0ccA83tYstwBwPHY6X67t_75_TUyBctk=.c27fbe65-0c06-46a8-84ec-52e69c7ee3de@github.com>
References: <OWzenp1llVs0ccA83tYstwBwPHY6X67t_75_TUyBctk=.c27fbe65-0c06-46a8-84ec-52e69c7ee3de@github.com>
Message-ID: <FeczG-AfDCby_2haZpcaJAvboVYZdyF-mZJeCClyD84=.36acca6e-a530-427a-b02b-9c5817067222@github.com>

On Thu, 22 Jun 2023 23:56:46 GMT, Justin Lu <jlu at openjdk.org> 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 <jlu at openjdk.org>
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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com>
Message-ID: <DHsPmaw514weQ3QuxQzTlTp_f__tOgaBPSB3AZewKnk=.d63af7ad-bfde-44cc-a148-08cde224e0d2@github.com>

On Mon, 10 Jul 2023 16:20:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <DHsPmaw514weQ3QuxQzTlTp_f__tOgaBPSB3AZewKnk=.d63af7ad-bfde-44cc-a148-08cde224e0d2@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com>
 <DHsPmaw514weQ3QuxQzTlTp_f__tOgaBPSB3AZewKnk=.d63af7ad-bfde-44cc-a148-08cde224e0d2@github.com>
Message-ID: <ACwbG5VhemDQiQHJsXP06r7Z8DG_a6a8Tm0dvVVqt2k=.bcae47d2-4063-4315-8ae7-7e1e0f363b46@github.com>

On Tue, 11 Jul 2023 21:09:15 GMT, Roger Riggs <rriggs at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <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 <bpb at openjdk.org> 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: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>

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: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <nx1fOnnGD7eHw-oJEt1vD7Y99rmInjK-v7F7JbxdFSg=.1fcd91d8-170f-4738-9ffd-d95a2e4b21b9@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> 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: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
Message-ID: <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>

On Mon, 3 Jul 2023 20:53:34 GMT, Glavo <duke at openjdk.org> 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: <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
Message-ID: <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>

On Wed, 12 Jul 2023 13:26:03 GMT, Alan Bateman <alanb at openjdk.org> 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: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
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: <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
Message-ID: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>

On Wed, 12 Jul 2023 14:31:53 GMT, Glavo <duke at openjdk.org> 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: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
Message-ID: <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>

On Wed, 12 Jul 2023 16:05:03 GMT, Uwe Schindler <uschindler at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <cgLZamef9Ebuci-h8pp7LykNfKU4ftzRQhXxPfwIKn8=.8f5e1f58-c48f-4242-bde5-945c2eef0ed9@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: 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <6w3i-y5a7qaMhcZ87DNXsd9w2gESNT-iFCvKRDeKCnc=.7cf8bef1-1eb1-4db8-84f4-f34ff283233d@github.com>
 <7YV4eHMOo9CNIIvXAzKh4qaJU7iNx-l9I3Lo1DUJgnY=.5e7ece74-2bf2-445d-a5fc-c63e026b1cd3@github.com>
Message-ID: <bApyC9M7V8XdE8GJL4dLlTNlqZf_kOduaBA7En_wqFA=.5430a2c7-0be9-4901-9214-ac60a15c6322@github.com>

On Wed, 12 Jul 2023 11:30:41 GMT, Alan Bateman <alanb at openjdk.org> 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: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>

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: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
References: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
Message-ID: <e1XObr5K1ChBAsshzDKxtyosVfnUWfkeUpMB11YPiOo=.1c9049fe-80af-4593-97ca-5d7db0407262@github.com>

On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
References: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
Message-ID: <suBU8y7H04hOv-kSbgV0bcVq9jl7xpa71pyfKBFk5W0=.ca6930a1-5b6f-4434-b2fa-8527dadfb69a@github.com>

On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
References: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
Message-ID: <ftNRg9CK5GExlKu0c_fejXJbzom2jfAOycOECW46WaQ=.6d102c9d-e21a-4864-83ca-0c14efcd2161@github.com>

> 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: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
References: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
Message-ID: <NSmGHmuFzbYVp_CwB6XIEKAnZoPuEqsio2jLeMWbZIc=.8ab61386-a81d-431f-ac38-f2905ca3b6a4@github.com>

On Thu, 13 Jul 2023 09:19:42 GMT, Matthias Baesken <mbaesken at openjdk.org> 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 <mbaesken at openjdk.org>
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: <ftNRg9CK5GExlKu0c_fejXJbzom2jfAOycOECW46WaQ=.6d102c9d-e21a-4864-83ca-0c14efcd2161@github.com>
References: <QhtyqWWxT3oQr0RXF1gSfLYvQsqa9bEzlYgKD9NVBHk=.5bc68c4c-b982-484d-823a-6f4f1f7c089f@github.com>
 <ftNRg9CK5GExlKu0c_fejXJbzom2jfAOycOECW46WaQ=.6d102c9d-e21a-4864-83ca-0c14efcd2161@github.com>
Message-ID: <IXYLKoY3lpTyh7BIX8vX-1fP8anpOTQSaqJ5u-bdEhM=.21865dbe-b4bf-442e-8f46-dc459607dc74@github.com>

On Thu, 13 Jul 2023 13:55:23 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>

On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <code>end&nbsp;-&nbsp;start</code>&nbsp;{@code >}&nbsp;
> 1463:      * {@code limit()}&nbsp;-&nbsp;{@code index},

Suggestion:

     * <code>end&nbsp;-&nbsp;start&nbsp;&gt;&nbsp;limit()&nbsp;-&nbsp;index</code>,

src/java.base/share/classes/java/nio/X-Buffer.java.template line 1490:

> 1488:      * <ul>
> 1489:      * <li>defines the range of characters to be read from the source in terms
> 1490:      * of the half-open interval {@code [start,}&nbsp;{@code  end)} instead of

Suggestion:

     * of the half-open interval <code>[start,&nbsp;end)</code> instead of

src/java.base/share/classes/java/nio/X-Buffer.java.template line 1495:

> 1493:      * {@code IndexOutOfBoundsException} for the condition
> 1494:      * {@code index}&nbsp;{@code +}&nbsp;{@code end}&nbsp;{@code -}&nbsp;
> 1495:      * {@code start}&nbsp;{@code >}&nbsp;{@code limit()}.</li>

Suggestion:

     * <code>index&nbsp;+&nbsp;end&nbsp;-&nbsp;start&nbsp;&gt;&nbsp;limit()</code>.</li>

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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <8IsqOile1vSs_LV8hgL-rEjn1Rly1OO0aX_shMOm3l4=.9a8c56be-ca2c-46aa-9167-fd0900d691bb@github.com>

On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * }</pre>

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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <8IsqOile1vSs_LV8hgL-rEjn1Rly1OO0aX_shMOm3l4=.9a8c56be-ca2c-46aa-9167-fd0900d691bb@github.com>
Message-ID: <oLbcdXDVnJD0TDvWHSeG2ZXsgodZCtNabSnXJeqTPks=.b5b18e62-3afc-4ec0-a879-d60b051f607d@github.com>

On Tue, 2 May 2023 03:03:49 GMT, Chen Liang <liach at openjdk.org> 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:      * }</pre>
> 
> 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 `<pre>{@code ...}</pre>` 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: <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
Message-ID: <seBphshox5DpVxx4_e7GcfKIqlvEs_MVFrkTXhighsY=.99d717d7-b5a6-4aea-867b-a632b966a657@github.com>

On Thu, 4 May 2023 04:13:47 GMT, ExE Boss <duke at openjdk.org> 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:      * <ul>
>> 1489:      * <li>defines the range of characters to be read from the source in terms
>> 1490:      * of the half-open interval {@code [start,}&nbsp;{@code  end)} instead of
> 
> Suggestion:
> 
>      * of the half-open interval <code>[start,&nbsp;end)</code> instead of

I was under the perhaps mistaken impression that `{@code ...}` is preferred to `<code>...</code>` 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>

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: <seBphshox5DpVxx4_e7GcfKIqlvEs_MVFrkTXhighsY=.99d717d7-b5a6-4aea-867b-a632b966a657@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
 <seBphshox5DpVxx4_e7GcfKIqlvEs_MVFrkTXhighsY=.99d717d7-b5a6-4aea-867b-a632b966a657@github.com>
Message-ID: <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com>

On Thu, 4 May 2023 20:39:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1490:
>> 
>>> 1488:      * <ul>
>>> 1489:      * <li>defines the range of characters to be read from the source in terms
>>> 1490:      * of the half-open interval {@code [start,}&nbsp;{@code  end)} instead of
>> 
>> Suggestion:
>> 
>>      * of the half-open interval <code>[start,&nbsp;end)</code> instead of
>
> I was under the perhaps mistaken impression that `{@code ...}` is preferred to `<code>...</code>` these days.

I think he suggested this because `&nbsp;` 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
 <seBphshox5DpVxx4_e7GcfKIqlvEs_MVFrkTXhighsY=.99d717d7-b5a6-4aea-867b-a632b966a657@github.com>
 <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 <liach at openjdk.org> wrote:

>> I was under the perhaps mistaken impression that `{@code ...}` is preferred to `<code>...</code>` these days.
>
> I think he suggested this because `&nbsp;` HTML code will not render into a no-break space in a `{@code}` block.

And that's exactly why `&nbsp;` 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <chTgmov_TRAN9gbx7-oXX34l9RHdW3FkHpIPvYWoYpU=.0930765e-f7c5-4e5f-9ad9-05dd0d2609b6@github.com>

On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <Me-Iq9lJ0DZntdR-QOx_EI6nl6APnxIP51Dwpqpv_Ms=.8cc955ee-fb91-4639-9ac8-8911fd247724@github.com>

On Mon, 1 May 2023 20:15:10 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <eagDmdQ5PrIIFUtEAQRHXptf52oDGYR6zkirhl54x3I=.ef8da640-63ef-4100-bf3a-3090d644baa1@github.com>

> 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
 <seBphshox5DpVxx4_e7GcfKIqlvEs_MVFrkTXhighsY=.99d717d7-b5a6-4aea-867b-a632b966a657@github.com>
 <5pNUiTIWg506hjexCyc8HMJraiiDpYFEROH3tGG2F2A=.dbcf231c-db6f-43cf-9f69-904fd98e8292@github.com>
 <9nzXzvSONw8OFvrCnImESBaBOZC2uBFqbaWR6Kz0kzo=.d37c24a1-7766-40ed-b900-391503e42b57@github.com>
Message-ID: <L4IdSFwmu5yO44aT3gCbUrmqRbhSzQpKsjIN5EGV8Dk=.38e618c0-a8e0-4bd1-9be5-e560698c2c46@github.com>

On Thu, 4 May 2023 21:03:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think he suggested this because `&nbsp;` HTML code will not render into a no-break space in a `{@code}` block.
>
> And that's exactly why `&nbsp;` 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: <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <yKlI_mE57rdHbUZAyVpW284MLGLa15oYUyoQ2AbM3cA=.4abfb5f5-35f8-4f41-91b4-8a1d967ada7c@github.com>
Message-ID: <UJ2T2UAN936ZOqgloDNFYar6XVHB5uuB_H1TrR7X7I0=.9151ef4d-0e12-4e5f-b4fd-5ba585e9bc86@github.com>

On Thu, 4 May 2023 07:30:52 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   4860681: Change some {@code ...} to <code>...</code> to prevent line breaking
>
> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1463:
> 
>> 1461:      * that is, if
>> 1462:      * <code>end&nbsp;-&nbsp;start</code>&nbsp;{@code >}&nbsp;
>> 1463:      * {@code limit()}&nbsp;-&nbsp;{@code index},
> 
> Suggestion:
> 
>      * <code>end&nbsp;-&nbsp;start&nbsp;&gt;&nbsp;limit()&nbsp;-&nbsp;index</code>,

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}&nbsp;{@code +}&nbsp;{@code end}&nbsp;{@code -}&nbsp;
>> 1495:      * {@code start}&nbsp;{@code >}&nbsp;{@code limit()}.</li>
> 
> Suggestion:
> 
>      * <code>index&nbsp;+&nbsp;end&nbsp;-&nbsp;start&nbsp;&gt;&nbsp;limit()</code>.</li>

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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <OJxqC0JVC3VcfmN5dKxbTKS-xP3pHiO93A7mJOhsUYA=.6ac5fb7c-322c-46db-89f8-d854e3ed30f5@github.com>

> 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 <code>...</code> 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: <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
Message-ID: <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>

On Wed, 12 Jul 2023 16:17:49 GMT, Glavo <duke at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@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.

-------------

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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <lPQXEq6XGgYpWyGvP4FEoV3RWRetJ7wzjdck29rPjR8=.a74a8a82-0ae1-403f-9a53-f5c21796ee57@github.com>

On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo <prappo at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <H_qrpdi42czYhiMJKICaLd9b44dvKH0jx2QUqL3yrs0=.3fd4f34e-3475-4d52-9a6f-580752659268@github.com>

On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo <prappo at openjdk.org> 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: <cgLZamef9Ebuci-h8pp7LykNfKU4ftzRQhXxPfwIKn8=.8f5e1f58-c48f-4242-bde5-945c2eef0ed9@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <cgLZamef9Ebuci-h8pp7LykNfKU4ftzRQhXxPfwIKn8=.8f5e1f58-c48f-4242-bde5-945c2eef0ed9@github.com>
Message-ID: <LVlnDPKgQztHFjyZ23ewLvUVhe3Z5b8H1Uhbi-5OdmE=.d671732c-862d-469b-af19-7d0a50f00404@github.com>

On Wed, 12 Jul 2023 17:09:25 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
 <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
Message-ID: <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>

On Fri, 14 Jul 2023 10:24:47 GMT, Alan Bateman <alanb at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@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 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: <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
 <Lb7gqaFf_SOuR4pXtDc-Nv5HvoITkO2KwvFfKAaZmyg=.6cbdf125-b849-49cc-912b-e6878afafd88@github.com>
 <p75Ux1Pkzvj0y6hTkCnGu6SDj-nx0zJBmV21O93I7w8=.794977d0-1c39-49a6-a75d-6f16a2a0e3b2@github.com>
 <picDy-h-ddC_h1hO0gzuV6xd-wUUnaSJdskQBlTxGIM=.0d274bff-b77d-4a0b-996b-1fd3c59b6608@github.com>
Message-ID: <fR-qsozihUcKtgZA3zegbWGh272Qjy48649sP0sxiB8=.627391bb-3e22-4746-99b2-4d18ac414439@github.com>

On Fri, 14 Jul 2023 13:01:46 GMT, Glavo <duke at openjdk.org> 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: <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
References: <FeOgGRRNlU26Ise2MfhplIaPxul_YfOZNvbdYR161I0=.ec4cb067-1460-4beb-bdd7-fbafbaee76bc@github.com>
 <GThInQakDD_gUmJKuartpwiGfcNFSL0RpBAh6ia3Uf0=.3dd95223-48e0-47b4-a97f-0005bfc33faf@github.com>
 <qNfFCDiE8DYJna7MXp77UnasD8Vg3iU6HBm5c4KVgu0=.0be8245d-3ff2-43b6-bd79-a258569013ad@github.com>
 <wcIqS-Z73fwLZICL2uhFveTBVYMYO2dtanzNtfm6PFA=.18624ed6-39fb-4b69-b777-7c293816d974@github.com>
Message-ID: <1059971530.104670971.1689341367155.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Uwe Schindler" <uschindler at openjdk.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>, 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 <duke at openjdk.org> 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: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
Message-ID: <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com>

On Fri, 14 Jul 2023 13:16:27 GMT, Pavel Rappo <prappo at openjdk.org> 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:

    /**
       ...
     * <p> Every charset has a <i>canonical name</i> and may also have one or more
     * <i>aliases</i>.  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<Charset>
    {
        ...
      
        /**
         * Compares this charset to another.
         *
         * <p> 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.
         *
         * <p> 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.  </p>
         *
         * @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<T> {
        /**
           ...
         * @apiNote
         * It is strongly recommended, but <i>not</i> 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: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
Message-ID: <LQPK7p4sUWNArkm4LthCIcBMTgUEXu2iYdAspoj8rQ8=.f26391e4-7a53-4684-a8bd-45a884346e72@github.com>

> 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: <OJxqC0JVC3VcfmN5dKxbTKS-xP3pHiO93A7mJOhsUYA=.6ac5fb7c-322c-46db-89f8-d854e3ed30f5@github.com>
References: <U9x9M_GAxP0ovSwqudochccInOuOY3c8JglRoQDUOgY=.62beb69d-20c6-4828-a4e8-b323a406f8aa@github.com>
 <OJxqC0JVC3VcfmN5dKxbTKS-xP3pHiO93A7mJOhsUYA=.6ac5fb7c-322c-46db-89f8-d854e3ed30f5@github.com>
Message-ID: <NyBQoTLTlBwjWHh7-XttdLNP-BCejzhzF7P5UYZ7F5w=.e315c14f-0531-4a7b-988d-7171c5c7caeb@github.com>

On Thu, 13 Jul 2023 19:28:24 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <code>...</code> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
 <7HA73ob9WWD-IAiPKql9ZCKi_BFlsgPmyY1xfuIxoJc=.81f2dfd6-ab26-43df-ab63-364fdc1843f9@github.com>
Message-ID: <goCHyYJ44TDyB5BcI5l5TdCgTXX7bugho1NLXljbSEk=.0883acf4-e3e2-4599-bf60-3ada6b494608@github.com>

On Fri, 14 Jul 2023 14:42:47 GMT, Pavel Rappo <prappo at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <gVU7ZPi-5T3s9u4ucBSz8jWuljmkjcynHdXC4kVIsT4=.ec6a63b3-c955-4bb1-bf0f-c4bc9ab42aec@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: 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: <LVlnDPKgQztHFjyZ23ewLvUVhe3Z5b8H1Uhbi-5OdmE=.d671732c-862d-469b-af19-7d0a50f00404@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <cgLZamef9Ebuci-h8pp7LykNfKU4ftzRQhXxPfwIKn8=.8f5e1f58-c48f-4242-bde5-945c2eef0ed9@github.com>
 <LVlnDPKgQztHFjyZ23ewLvUVhe3Z5b8H1Uhbi-5OdmE=.d671732c-862d-469b-af19-7d0a50f00404@github.com>
Message-ID: <hcEPqNySv7wb1MMpu_s2H1ZZp7WR0f8NUV3VwPUhPH0=.4ed6f505-399e-4552-8cd5-1a6107fd2e9e@github.com>

On Fri, 14 Jul 2023 11:11:22 GMT, Alan Bateman <alanb at openjdk.org> 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: <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
Message-ID: <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>

On Fri, 14 Jul 2023 13:16:27 GMT, Pavel Rappo <prappo at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
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: <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <aPlljRyFAmMHxxmrnI-a9-caCvXwT-MUmZmHNuJ6wok=.76f1f291-9d99-4d4a-bac2-b89ba0c291bb@github.com>
 <n_QuByqx_RJ-vSW_mceUefS2DoZ_xx4ozfcn7jJAV8I=.b3afdc7c-cf6a-45dd-8cb0-3e9b438f1618@github.com>
Message-ID: <rBQpIQycxsxPQvtNlox1zQyYO9B1opFRQ7rLczE605M=.a58a3a23-f912-4464-a1e0-2c6c602c3536@github.com>

On Fri, 14 Jul 2023 16:42:02 GMT, Alan Bateman <alanb at openjdk.org> 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: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
Message-ID: <V1vMQHp1FLo-dXOjXV_DlGauJ-FOuKatniPzGBcQLto=.d4847258-a6fc-47ad-8341-93d6f085509f@github.com>

> 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: <LzF1Zh8D7bd8wayZZpo-vUChr1KIa7aJ985TSlh29Yw=.a602f13c-9793-4b03-a7ed-c43de0362454@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <LxPIznoIS35wQKnn_5IEoAcMuC-VcLHY3NRl9fntIdI=.905dd658-dcc6-4c00-9488-8834c6cfe997@github.com>
 <LzF1Zh8D7bd8wayZZpo-vUChr1KIa7aJ985TSlh29Yw=.a602f13c-9793-4b03-a7ed-c43de0362454@github.com>
Message-ID: <63iX12Vms8a0Wfnhh1TN9FQaYRAQvKPxIIcaL9HRDd4=.f1d55857-3aba-4b08-8d73-9262181eb727@github.com>

On Thu, 27 Apr 2023 06:52:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
Message-ID: <x3V45gFuV7sXlIBvMXKOtPUA0w1n2IAjteDuNuqFnVs=.9ce013b4-0716-4358-acc4-7015e3e3bb74@github.com>

On Fri, 14 Jul 2023 18:54:35 GMT, Pavel Rappo <prappo at openjdk.org> 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: <gVU7ZPi-5T3s9u4ucBSz8jWuljmkjcynHdXC4kVIsT4=.ec6a63b3-c955-4bb1-bf0f-c4bc9ab42aec@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <gVU7ZPi-5T3s9u4ucBSz8jWuljmkjcynHdXC4kVIsT4=.ec6a63b3-c955-4bb1-bf0f-c4bc9ab42aec@github.com>
Message-ID: <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com>

On Fri, 14 Jul 2023 16:49:05 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
 <6I_ZpsYUKuSLeGx-V-yXD6LmPfxZn_seP2oiloCrPgA=.d474a89d-2beb-4326-83d0-47c585cc56b1@github.com>
Message-ID: <rBvDiZx6uHt4Hpfw5Jf7rC26kXN0kN9_jUT9FWSVpu8=.28a470c9-f8cf-4193-899d-b88abd84279d@github.com>

On Fri, 14 Jul 2023 18:54:35 GMT, Pavel Rappo <prappo at openjdk.org> 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: <V1vMQHp1FLo-dXOjXV_DlGauJ-FOuKatniPzGBcQLto=.d4847258-a6fc-47ad-8341-93d6f085509f@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <V1vMQHp1FLo-dXOjXV_DlGauJ-FOuKatniPzGBcQLto=.d4847258-a6fc-47ad-8341-93d6f085509f@github.com>
Message-ID: <4nfS28vNfmvhJQIIYlAvdGMfYqNUbF5J1hFh6FFx-4k=.1490f91a-b237-4605-b3dc-0aca569051b3@github.com>

On Fri, 14 Jul 2023 22:16:11 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>

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: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <V1vMQHp1FLo-dXOjXV_DlGauJ-FOuKatniPzGBcQLto=.d4847258-a6fc-47ad-8341-93d6f085509f@github.com>
 <4nfS28vNfmvhJQIIYlAvdGMfYqNUbF5J1hFh6FFx-4k=.1490f91a-b237-4605-b3dc-0aca569051b3@github.com>
Message-ID: <kJQnoy8imSyzn29dXDqlvfTPBdu-AuZ0mmwV7d_l4QQ=.531be3d1-8768-431c-b636-6673e0d60d92@github.com>

On Mon, 17 Jul 2023 06:08:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
Message-ID: <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>

> 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: <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
Message-ID: <wO-HyCmkNi44b0OWxhal2fthbO4u9NTNssgXtqCZ2tQ=.fe970e64-0b42-4f75-9647-1604106493f1@github.com>

On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <wO-HyCmkNi44b0OWxhal2fthbO4u9NTNssgXtqCZ2tQ=.fe970e64-0b42-4f75-9647-1604106493f1@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
 <wO-HyCmkNi44b0OWxhal2fthbO4u9NTNssgXtqCZ2tQ=.fe970e64-0b42-4f75-9647-1604106493f1@github.com>
Message-ID: <NuHDHGUa6-2VjYN8dfJqE74xn9wY0pbc2x_ujZPhzLA=.2a9d7158-e989-4c51-ae68-13b502b1fcc3@github.com>

On Mon, 17 Jul 2023 17:57:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <F0xbOb0a69POAS6xF93BnztoeMK6JFX2ZlLkNrbex8o=.c321461a-610c-4698-8fbb-1ccdae6183a3@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: 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <gVU7ZPi-5T3s9u4ucBSz8jWuljmkjcynHdXC4kVIsT4=.ec6a63b3-c955-4bb1-bf0f-c4bc9ab42aec@github.com>
 <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com>
Message-ID: <s3W9QMbcx84pxUXQ8GUmTVGUbWyv1t7TG_fnzp2PyLU=.514c9078-2ef9-462f-a654-923263736dfc@github.com>

On Sat, 15 Jul 2023 07:11:03 GMT, Alan Bateman <alanb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <PghHsX639EUtCUIYUkun7VbHCsDe2i16fmtyux7mibE=.7d2d135e-1d71-47af-9576-1974fb0d90d3@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: 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: <ACwbG5VhemDQiQHJsXP06r7Z8DG_a6a8Tm0dvVVqt2k=.bcae47d2-4063-4315-8ae7-7e1e0f363b46@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com>
 <DHsPmaw514weQ3QuxQzTlTp_f__tOgaBPSB3AZewKnk=.d63af7ad-bfde-44cc-a148-08cde224e0d2@github.com>
 <ACwbG5VhemDQiQHJsXP06r7Z8DG_a6a8Tm0dvVVqt2k=.bcae47d2-4063-4315-8ae7-7e1e0f363b46@github.com>
Message-ID: <ZAanYJa-G3SIPUt242ycPv293SKyPN7PEKRyemu9uQ0=.ed0d7fd8-3b98-403c-9055-6cafa8a0198b@github.com>

On Wed, 12 Jul 2023 00:48:30 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
References: <DOmlSbkKJGKzlmEvr4lr6819gVOCFil1cTvz3u9frvs=.6d6c216b-a3b9-4e68-985d-f4b97ca8f9ed@github.com>
Message-ID: <nxnJNw93FH3Nxct_Tk8u0ISP-8RTeR5NcSccYV64Des=.5453c867-282c-4657-a0b6-348076885a40@github.com>

On Fri, 14 Jul 2023 12:06:29 GMT, Pavel Rappo <prappo at openjdk.org> 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 <prappo at openjdk.org>
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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>

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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
Message-ID: <WM4uCA_XGsWAfPGPesS3IHal-ow3fJa8R4C3cFNtUzs=.7520af14-608b-406d-b4d4-5b537ba2103b@github.com>

On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele <tsteele at openjdk.org> 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: <AwwAO4OVTQv4OPuPR-U7-i8gMI06g-tM51iPYZew7XI=.fc45f767-7842-4d15-80d6-2b607ba0e417@github.com>

Solves the issue by searching `/proc/<pid>/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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
Message-ID: <bt3YVJBsC-vjAvKwdHbTTc_-_iSuYq8Z8XPBiXAT2w0=.56be7f0a-d899-46c7-9adb-c08b8a979af2@github.com>

On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele <tsteele at openjdk.org> 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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
Message-ID: <QYE6B7zkD2UizDUyEh6Mqt12XhBr1_T8ZVmFxBCFQGA=.b3d009be-b136-4bc2-8401-db64b3696d7d@github.com>

On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele <tsteele at openjdk.org> 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: <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
Message-ID: <aM05jBoVzIoJ183sO5V1FmtNyF0jrxad25cn4-IEylw=.9f9119e4-5922-4059-a8d6-84ad9bd6d50f@github.com>

On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
Message-ID: <d2T9TZ1r2doMFkoejpR00Lb9nBTvwr28m82oRvAddUI=.617d97f2-fe7c-4daf-a158-4e0fcbc8a421@github.com>

On Mon, 17 Jul 2023 17:52:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <F0xbOb0a69POAS6xF93BnztoeMK6JFX2ZlLkNrbex8o=.c321461a-610c-4698-8fbb-1ccdae6183a3@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <F0xbOb0a69POAS6xF93BnztoeMK6JFX2ZlLkNrbex8o=.c321461a-610c-4698-8fbb-1ccdae6183a3@github.com>
Message-ID: <iVgqA6xQOl2aIQF42KVS_o1DNG88ABhP2Vh8O8xKWfo=.2ad6140d-97de-470d-abbb-16e4dfc62dab@github.com>

On Mon, 17 Jul 2023 19:10:41 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <BbsJdvT_0XJit1psbRWHm8SVAtwopYrqLmBzfD5dLBs=.e183513d-605e-4423-8e7f-19751a3f64cd@github.com>

On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman <alanb at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <SZHuB3trENPKpyzL2zXV-Ocjab3l5XwQfRXEZm3rVGw=.5c2852b1-e819-46b2-a2c9-9e9e26956a59@github.com>

On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman <alanb at openjdk.org> 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: <SZHuB3trENPKpyzL2zXV-Ocjab3l5XwQfRXEZm3rVGw=.5c2852b1-e819-46b2-a2c9-9e9e26956a59@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <SZHuB3trENPKpyzL2zXV-Ocjab3l5XwQfRXEZm3rVGw=.5c2852b1-e819-46b2-a2c9-9e9e26956a59@github.com>
Message-ID: <xwQV08ys273lN8nb1u1l1SsuRTF3JIXSd6VbjYAOc9s=.24104b0c-f13b-4be1-aeb8-3459141f89b8@github.com>

On Tue, 18 Jul 2023 13:50:51 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <BbsJdvT_0XJit1psbRWHm8SVAtwopYrqLmBzfD5dLBs=.e183513d-605e-4423-8e7f-19751a3f64cd@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <BbsJdvT_0XJit1psbRWHm8SVAtwopYrqLmBzfD5dLBs=.e183513d-605e-4423-8e7f-19751a3f64cd@github.com>
Message-ID: <XCKXOmgoXVW61KphiJLa5Ufio3KXimYerKSQmtRg1_I=.a5e8bd89-33be-4ece-a4ec-7842f631a8ea@github.com>

On Tue, 18 Jul 2023 13:38:12 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <xwQV08ys273lN8nb1u1l1SsuRTF3JIXSd6VbjYAOc9s=.24104b0c-f13b-4be1-aeb8-3459141f89b8@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <SZHuB3trENPKpyzL2zXV-Ocjab3l5XwQfRXEZm3rVGw=.5c2852b1-e819-46b2-a2c9-9e9e26956a59@github.com>
 <xwQV08ys273lN8nb1u1l1SsuRTF3JIXSd6VbjYAOc9s=.24104b0c-f13b-4be1-aeb8-3459141f89b8@github.com>
Message-ID: <I4je9nbtX9rHNBJBBFQQFktD-sJ-a-3xnINkeh57ZyU=.20b6b060-98cb-4bc1-92ce-ef9260890fe4@github.com>

On Tue, 18 Jul 2023 14:03:19 GMT, Alan Bateman <alanb at openjdk.org> 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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
Message-ID: <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>

On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele <tsteele at openjdk.org> 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: <bt3YVJBsC-vjAvKwdHbTTc_-_iSuYq8Z8XPBiXAT2w0=.56be7f0a-d899-46c7-9adb-c08b8a979af2@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <bt3YVJBsC-vjAvKwdHbTTc_-_iSuYq8Z8XPBiXAT2w0=.56be7f0a-d899-46c7-9adb-c08b8a979af2@github.com>
Message-ID: <NbTbwOcPrUkitGqQANGDRjKVM8-sg09N-lkTUZtxArE=.ea4e045a-1783-416e-afd1-03d49979efc9@github.com>

On Tue, 18 Jul 2023 02:08:42 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <aM05jBoVzIoJ183sO5V1FmtNyF0jrxad25cn4-IEylw=.9f9119e4-5922-4059-a8d6-84ad9bd6d50f@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
 <aM05jBoVzIoJ183sO5V1FmtNyF0jrxad25cn4-IEylw=.9f9119e4-5922-4059-a8d6-84ad9bd6d50f@github.com>
Message-ID: <bKVgNI2L3E_tx0k-wAcHGyuqTtL8c0ZGQZ4_e33pEh0=.ece7bf09-81c8-4c5c-9da0-83f082841752@github.com>

On Tue, 18 Jul 2023 05:38:29 GMT, Vyom Tewari <vtewari at openjdk.org> 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: <NbTbwOcPrUkitGqQANGDRjKVM8-sg09N-lkTUZtxArE=.ea4e045a-1783-416e-afd1-03d49979efc9@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <bt3YVJBsC-vjAvKwdHbTTc_-_iSuYq8Z8XPBiXAT2w0=.56be7f0a-d899-46c7-9adb-c08b8a979af2@github.com>
 <NbTbwOcPrUkitGqQANGDRjKVM8-sg09N-lkTUZtxArE=.ea4e045a-1783-416e-afd1-03d49979efc9@github.com>
Message-ID: <qjsutDq8SJlqArME3wo_qaoOJglancVzqyPoxG12fCg=.552b7317-0165-4268-82b1-99a4f48c0eb3@github.com>

On Tue, 18 Jul 2023 15:33:59 GMT, Tyler Steele <tsteele at openjdk.org> 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: <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
Message-ID: <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com>

On Tue, 18 Jul 2023 15:30:23 GMT, Tyler Steele <tsteele at openjdk.org> 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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
 <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com>
Message-ID: <QllJbLjxHhZO_u9T37_1qTTdUmZwJ5rDCEayol_M_7g=.861293b5-0075-4843-9c94-5e5842e4ca11@github.com>

On Tue, 18 Jul 2023 15:52:53 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
 <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com>
Message-ID: <OmcZbFYppvtjrUPf0NEnJzkaILk63yYSYfndMXZb0mo=.d4d363a4-84b5-49e2-91b3-cc58d72517a0@github.com>

On Tue, 18 Jul 2023 15:52:53 GMT, Thomas Stuefe <stuefe at openjdk.org> 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: <bKVgNI2L3E_tx0k-wAcHGyuqTtL8c0ZGQZ4_e33pEh0=.ece7bf09-81c8-4c5c-9da0-83f082841752@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
 <WGxABv0DfMkZOChNN6RlcYR7BqFYvPfI7uYkKHApm9o=.aea19857-cff7-4cc0-8cee-c8af569c64fe@github.com>
 <aM05jBoVzIoJ183sO5V1FmtNyF0jrxad25cn4-IEylw=.9f9119e4-5922-4059-a8d6-84ad9bd6d50f@github.com>
 <bKVgNI2L3E_tx0k-wAcHGyuqTtL8c0ZGQZ4_e33pEh0=.ece7bf09-81c8-4c5c-9da0-83f082841752@github.com>
Message-ID: <eFCpq97oBpDi2DYTXbnAEM149gtfLiGPyIhU1lPbrGY=.7ada4bde-92d2-4c14-9db2-b8dec17124ba@github.com>

On Tue, 18 Jul 2023 15:36:00 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <OmcZbFYppvtjrUPf0NEnJzkaILk63yYSYfndMXZb0mo=.d4d363a4-84b5-49e2-91b3-cc58d72517a0@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
 <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com>
 <OmcZbFYppvtjrUPf0NEnJzkaILk63yYSYfndMXZb0mo=.d4d363a4-84b5-49e2-91b3-cc58d72517a0@github.com>
Message-ID: <ACRc944wivSISRdZLeYvzZQ-IUKwPteohVrkSTTnQrg=.a8048703-eff0-4077-a904-cc11365ed462@github.com>

On Tue, 18 Jul 2023 16:15:30 GMT, Alan Bateman <alanb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <xoFAfUwqkIH8dZpS1-i2hdj5drbSScCuzjQ8nkH7BHY=.a3e6d543-4e70-4622-9298-e921af0464e5@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: 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: <OmcZbFYppvtjrUPf0NEnJzkaILk63yYSYfndMXZb0mo=.d4d363a4-84b5-49e2-91b3-cc58d72517a0@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <JX-AFnNyUlut5nRUy7a0tqGr_Db9JX5T7-IjtdnluKI=.cc045303-57ae-445b-b065-eb03fa4b00cf@github.com>
 <-Qq--7MqQqWxGvFl-tmLxCzHBGXmvAyv2gzdFLkFXPY=.c8ae65e9-8d95-4276-9448-4157d7930bd1@github.com>
 <OmcZbFYppvtjrUPf0NEnJzkaILk63yYSYfndMXZb0mo=.d4d363a4-84b5-49e2-91b3-cc58d72517a0@github.com>
Message-ID: <YSi0isZKrBEvuHU0aiR6WevTdSkJdw-01hzCcA0BBz0=.1b1aa4ab-523c-469e-88e0-795daa6992ca@github.com>

On Tue, 18 Jul 2023 16:15:30 GMT, Alan Bateman <alanb at openjdk.org> 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: <s3W9QMbcx84pxUXQ8GUmTVGUbWyv1t7TG_fnzp2PyLU=.514c9078-2ef9-462f-a654-923263736dfc@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <gVU7ZPi-5T3s9u4ucBSz8jWuljmkjcynHdXC4kVIsT4=.ec6a63b3-c955-4bb1-bf0f-c4bc9ab42aec@github.com>
 <4LMpOBV2XVYwUZEhWje98KLkTrn3-zx8XRhGzkTdSbg=.d0fbbbc1-3865-42a8-a732-91c61597d3fa@github.com>
 <s3W9QMbcx84pxUXQ8GUmTVGUbWyv1t7TG_fnzp2PyLU=.514c9078-2ef9-462f-a654-923263736dfc@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 <bpb at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>

> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <wm6IPY_TeF5VQLs_NwjhEe-ULREieHBRZF0F2xp0L5A=.6cb3b06d-3f36-4f57-a717-99b76524d32e@github.com>

On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman <alanb at openjdk.org> 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: <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>
Message-ID: <lpiSOkOTwA6NM7xfRXT3eYt76axLNig3C1EO6tdjJg8=.114be13e-152d-4387-81cb-3813433efed5@github.com>

On Wed, 19 Jul 2023 10:31:15 GMT, Alan Bateman <alanb at openjdk.org> 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: <wm6IPY_TeF5VQLs_NwjhEe-ULREieHBRZF0F2xp0L5A=.6cb3b06d-3f36-4f57-a717-99b76524d32e@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <wm6IPY_TeF5VQLs_NwjhEe-ULREieHBRZF0F2xp0L5A=.6cb3b06d-3f36-4f57-a717-99b76524d32e@github.com>
Message-ID: <xRBHEWaTuLF5YT9r38SKZLHu6A66LaWL-jmZhimo3JU=.8220c71c-64ce-4276-92da-3979755a2bf8@github.com>

On Wed, 19 Jul 2023 10:29:25 GMT, Alan Bateman <alanb at openjdk.org> 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: <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>
Message-ID: <0ebo_TxjlNQUsgt2nIj10UelEOLqP8ssH8xmw7rk_gg=.d1405b8b-1262-4c98-9121-497cc07e4d4d@github.com>

On Wed, 19 Jul 2023 10:31:15 GMT, Alan Bateman <alanb at openjdk.org> 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: <lpiSOkOTwA6NM7xfRXT3eYt76axLNig3C1EO6tdjJg8=.114be13e-152d-4387-81cb-3813433efed5@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <XY30YvwAtyjYB5CmnVEN8-iCXLWPIHjWJNufb9RHjSo=.4f8f98f4-7efd-4f4e-b592-590c8929f457@github.com>
 <lpiSOkOTwA6NM7xfRXT3eYt76axLNig3C1EO6tdjJg8=.114be13e-152d-4387-81cb-3813433efed5@github.com>
Message-ID: <Cq0-pPLri8jqIjWyWG-EaaBltL31FakTKinTipFa4oo=.1bc8dd84-0770-48f5-86b4-728043592d39@github.com>

On Wed, 19 Jul 2023 11:29:21 GMT, Jaikiran Pai <jpai at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <OMrZtA258P1Y0hgZy-aHWI8x2ouUDAfWEp1MQN3Uo0M=.2a434d54-3877-4e24-9170-1d5d34d8adfe@github.com>

> 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: <OMrZtA258P1Y0hgZy-aHWI8x2ouUDAfWEp1MQN3Uo0M=.2a434d54-3877-4e24-9170-1d5d34d8adfe@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
 <OMrZtA258P1Y0hgZy-aHWI8x2ouUDAfWEp1MQN3Uo0M=.2a434d54-3877-4e24-9170-1d5d34d8adfe@github.com>
Message-ID: <oNGyIE5sPHVe-KFlg-ruGiZMdRrLNp6JqfisAD_2JY0=.ca60657b-8b60-4ace-bc21-28fba32209e1@github.com>

On Wed, 19 Jul 2023 12:38:31 GMT, Alan Bateman <alanb at openjdk.org> 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: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
References: <fj_vClRH1gJxyGAhGNS54sTzZ_cKx4WmZxI32ej20U0=.a4cd2b6a-f7d1-48db-9220-fb3db7853c67@github.com>
Message-ID: <DI6LMifdQQoE72HMeAik8pt8YoeIF0LkTpSoeTl8SEc=.94efc698-d124-4f67-9be3-7be3d999ceb3@github.com>

On Mon, 17 Jul 2023 10:10:20 GMT, Alan Bateman <alanb at openjdk.org> 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 <alanb at openjdk.org>
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: <xoFAfUwqkIH8dZpS1-i2hdj5drbSScCuzjQ8nkH7BHY=.a3e6d543-4e70-4622-9298-e921af0464e5@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <xoFAfUwqkIH8dZpS1-i2hdj5drbSScCuzjQ8nkH7BHY=.a3e6d543-4e70-4622-9298-e921af0464e5@github.com>
Message-ID: <U4YmcakI46C5HG1rA1BRlLCazyTMZsecpFk9_YQCblg=.673da5a7-6c4e-4584-8328-9701f3b22108@github.com>

On Tue, 18 Jul 2023 16:46:45 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <qjsutDq8SJlqArME3wo_qaoOJglancVzqyPoxG12fCg=.552b7317-0165-4268-82b1-99a4f48c0eb3@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
 <bt3YVJBsC-vjAvKwdHbTTc_-_iSuYq8Z8XPBiXAT2w0=.56be7f0a-d899-46c7-9adb-c08b8a979af2@github.com>
 <NbTbwOcPrUkitGqQANGDRjKVM8-sg09N-lkTUZtxArE=.ea4e045a-1783-416e-afd1-03d49979efc9@github.com>
 <qjsutDq8SJlqArME3wo_qaoOJglancVzqyPoxG12fCg=.552b7317-0165-4268-82b1-99a4f48c0eb3@github.com>
Message-ID: <7uSfR3HQA1heK_Rf6OwL2jtruS-cU-OgrcfFJzQ6Vl0=.2da0e62d-13f1-4496-ab5e-5f2c51b33d56@github.com>

On Tue, 18 Jul 2023 15:39:33 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <gYtvCjXLKB4bpNhpvC-NqID3Jkgrx56mHCGiWHWIErc=.547906b4-8b49-40ae-8444-ce45c84a344c@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: 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: <U4YmcakI46C5HG1rA1BRlLCazyTMZsecpFk9_YQCblg=.673da5a7-6c4e-4584-8328-9701f3b22108@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <xoFAfUwqkIH8dZpS1-i2hdj5drbSScCuzjQ8nkH7BHY=.a3e6d543-4e70-4622-9298-e921af0464e5@github.com>
 <U4YmcakI46C5HG1rA1BRlLCazyTMZsecpFk9_YQCblg=.673da5a7-6c4e-4584-8328-9701f3b22108@github.com>
Message-ID: <kF7CuVnnsvdD8135LGnMK7bsld6bXrypxXbLs_8TxB4=.d9a49d48-be8c-4b6e-8f5a-80ed41bc40c2@github.com>

On Wed, 19 Jul 2023 15:54:23 GMT, Roger Riggs <rriggs at openjdk.org> 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: <ZAanYJa-G3SIPUt242ycPv293SKyPN7PEKRyemu9uQ0=.ed0d7fd8-3b98-403c-9055-6cafa8a0198b@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <8HkEnHNSEWOlGshVGHZS-thsuKNgnQu27FC6Glx0xRQ=.3fa273ae-1525-4180-8bc6-38b270035795@github.com>
 <DHsPmaw514weQ3QuxQzTlTp_f__tOgaBPSB3AZewKnk=.d63af7ad-bfde-44cc-a148-08cde224e0d2@github.com>
 <ACwbG5VhemDQiQHJsXP06r7Z8DG_a6a8Tm0dvVVqt2k=.bcae47d2-4063-4315-8ae7-7e1e0f363b46@github.com>
 <ZAanYJa-G3SIPUt242ycPv293SKyPN7PEKRyemu9uQ0=.ed0d7fd8-3b98-403c-9055-6cafa8a0198b@github.com>
Message-ID: <t8YYce8OVbD5pHm5b6wUWAUVg-tiAAvSPSfqAn3IJLs=.8536987c-ddf8-41f7-8601-0366020f3e50@github.com>

On Mon, 17 Jul 2023 21:16:37 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <xj1ScYaOEouvTpBzWbB9SLoeNpS5tRB_1f3A8Wxpgyc=.c3747bd4-ba7f-4c0a-b525-3702ff23fe7b@github.com>
References: <xj1ScYaOEouvTpBzWbB9SLoeNpS5tRB_1f3A8Wxpgyc=.c3747bd4-ba7f-4c0a-b525-3702ff23fe7b@github.com>
Message-ID: <5UrSUIO1UhgQ1YY5U3ZcHu26sZakj8aHyknrRVEfJaQ=.2004671f-6620-4daa-9d49-560b3b3337cc@github.com>

On Fri, 30 Jun 2023 14:13:10 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <xj1ScYaOEouvTpBzWbB9SLoeNpS5tRB_1f3A8Wxpgyc=.c3747bd4-ba7f-4c0a-b525-3702ff23fe7b@github.com>
 <5UrSUIO1UhgQ1YY5U3ZcHu26sZakj8aHyknrRVEfJaQ=.2004671f-6620-4daa-9d49-560b3b3337cc@github.com>
Message-ID: <WFqcb_kJvRK1YEvi98T8eOWV5FFFrvH9axNAETLgiqo=.393555e4-3cd3-4769-a1e5-fcbc8138119f@github.com>

On Thu, 20 Jul 2023 06:44:46 GMT, Alan Bateman <alanb at openjdk.org> 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: <xj1ScYaOEouvTpBzWbB9SLoeNpS5tRB_1f3A8Wxpgyc=.c3747bd4-ba7f-4c0a-b525-3702ff23fe7b@github.com>
References: <xj1ScYaOEouvTpBzWbB9SLoeNpS5tRB_1f3A8Wxpgyc=.c3747bd4-ba7f-4c0a-b525-3702ff23fe7b@github.com>
Message-ID: <3cMCHhxiRvGJZVCiAuf4hJmBmS48D1u8di-WaloNNrk=.94cf2661-00c9-4ffd-80e2-c8ba27b12655@github.com>

On Fri, 30 Jun 2023 14:13:10 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <cPgIPh1EiOKn6DpntaPYtohSI36BRmr3ZD-c3eXmS54=.3f7681bd-5817-4685-89ac-6ac5709e9dfa@github.com>
References: <GcmYrGHu0sTUCHq4Uq6M748z_hXiemrp_FQf1E9nWbE=.3b62e201-c45b-434b-a515-6b195a04f755@github.com>
 <cPgIPh1EiOKn6DpntaPYtohSI36BRmr3ZD-c3eXmS54=.3f7681bd-5817-4685-89ac-6ac5709e9dfa@github.com>
Message-ID: <JOKuXfUOt7qU8lLKRE7MqH06ANr4TjXcBezoH8NNft4=.0fe3e2cc-8c3a-4739-940e-a52089b59347@github.com>

On Tue, 29 Nov 2022 10:47:16 GMT, Maxim Kartashev <mkartashev at openjdk.org> 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: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>

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: <AwwAO4OVTQv4OPuPR-U7-i8gMI06g-tM51iPYZew7XI=.fc45f767-7842-4d15-80d6-2b607ba0e417@github.com>
References: <AwwAO4OVTQv4OPuPR-U7-i8gMI06g-tM51iPYZew7XI=.fc45f767-7842-4d15-80d6-2b607ba0e417@github.com>
Message-ID: <eJyvrHqtJv7RF-fInb0vbjp53DvrbQCf4w5D8qc4Pto=.937f6529-7986-425b-8deb-ea9cd9be3aa6@github.com>

On Mon, 17 Jul 2023 23:20:10 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Solves the issue by searching `/proc/<pid>/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: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
References: <WqySgMImhqlruxvC_AEiwpDaf2eBY368PZHC6iVEWh4=.107f083b-e048-4e0e-89cd-a76025085d51@github.com>
Message-ID: <vUu8UVCxeDAjHp0hfYSV_slh2ZbEzQt14w86nrjZGvY=.6eab3e46-c025-4c21-9240-3544f5131f7b@github.com>

On Mon, 17 Jul 2023 17:21:01 GMT, Tyler Steele <tsteele at openjdk.org> 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: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
Message-ID: <ao9XqaxSE-48vW4b0ytVAqYf2glc-yotAFZbYJZMADM=.881bd533-b676-4a87-ae1b-1ecb7a768943@github.com>

On Thu, 20 Jul 2023 18:11:15 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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.  </p>

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: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
References: <wabLfz3uDPF-tFpylrV_JyUaQPCOte_D5CHW8DR-PJc=.e30749c5-b77e-4676-b328-8404851d09e1@github.com>
Message-ID: <ty8IYLkOdfuzZd1XBLHnLMOBl2PLDpAR3Ha269ELVec=.acc31bd3-790b-42d4-8646-3c876d25cc0b@github.com>

On Tue, 18 Apr 2023 02:03:19 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
Message-ID: <R80YwnemMPnOYtvNfp1_EbZEhIof2_1Z2ZjU-GL0dcs=.06245647-a452-4bda-974d-96f13ec0bae2@github.com>

> 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: <ao9XqaxSE-48vW4b0ytVAqYf2glc-yotAFZbYJZMADM=.881bd533-b676-4a87-ae1b-1ecb7a768943@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
 <ao9XqaxSE-48vW4b0ytVAqYf2glc-yotAFZbYJZMADM=.881bd533-b676-4a87-ae1b-1ecb7a768943@github.com>
Message-ID: <xcgdgFNtcOsEp0DGMbjvTerXjV7Wq1HCmewlYrRQezE=.eec8bdeb-a0ea-4cbc-81de-df8125f54e72@github.com>

On Fri, 21 Jul 2023 06:32:10 GMT, Alan Bateman <alanb at openjdk.org> 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:      * <p> 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.  </p>
> 
> 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: <R80YwnemMPnOYtvNfp1_EbZEhIof2_1Z2ZjU-GL0dcs=.06245647-a452-4bda-974d-96f13ec0bae2@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
 <R80YwnemMPnOYtvNfp1_EbZEhIof2_1Z2ZjU-GL0dcs=.06245647-a452-4bda-974d-96f13ec0bae2@github.com>
Message-ID: <QCTZ0oIJWtKzwIORK4OKQWeg8lRx5_tmT_s9-YnQZ4A=.4a14aaca-f092-4b1e-852a-4d82a700d071@github.com>

On Fri, 21 Jul 2023 15:43:07 GMT, Brian Burkhalter <bpb at openjdk.org> 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:      * <p> 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: <QCTZ0oIJWtKzwIORK4OKQWeg8lRx5_tmT_s9-YnQZ4A=.4a14aaca-f092-4b1e-852a-4d82a700d071@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
 <R80YwnemMPnOYtvNfp1_EbZEhIof2_1Z2ZjU-GL0dcs=.06245647-a452-4bda-974d-96f13ec0bae2@github.com>
 <QCTZ0oIJWtKzwIORK4OKQWeg8lRx5_tmT_s9-YnQZ4A=.4a14aaca-f092-4b1e-852a-4d82a700d071@github.com>
Message-ID: <qH1kB7NHJTcRLgdlXHab416HKHu8zbhnRb5Ke3Xexrc=.70d8d49b-9d81-4e3c-96de-ac0b2b35f000@github.com>

On Fri, 21 Jul 2023 16:25:37 GMT, Alan Bateman <alanb at openjdk.org> 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:      * <p> 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: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
Message-ID: <Cusscto3ic6yYBBjMBc6rV-SONc6ULr-xHPMyzjzRZQ=.ba24c553-67a0-4aaa-81c7-9f2c157ecef7@github.com>

> 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: <Cusscto3ic6yYBBjMBc6rV-SONc6ULr-xHPMyzjzRZQ=.ba24c553-67a0-4aaa-81c7-9f2c157ecef7@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
 <Cusscto3ic6yYBBjMBc6rV-SONc6ULr-xHPMyzjzRZQ=.ba24c553-67a0-4aaa-81c7-9f2c157ecef7@github.com>
Message-ID: <8zlYcbVMbVR37j-BzUTI5JQ9deXSRAm32Ka001hvztA=.963f90f3-b5a5-4d8b-a870-412f52e24319@github.com>

On Fri, 21 Jul 2023 16:35:55 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <gYtvCjXLKB4bpNhpvC-NqID3Jkgrx56mHCGiWHWIErc=.547906b4-8b49-40ae-8444-ce45c84a344c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
 <gYtvCjXLKB4bpNhpvC-NqID3Jkgrx56mHCGiWHWIErc=.547906b4-8b49-40ae-8444-ce45c84a344c@github.com>
Message-ID: <0R5tmTCqwAkc0ndvTF9DCRzH53bUfEj_foHy8KH3VoI=.46cb813f-a819-45ba-ab95-77a6ecd0f151@github.com>

On Thu, 20 Jul 2023 03:55:08 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
References: <fOEacy43sDUuqT7L7oaMyFYqBbSdHfLOsB3aQiqT8_E=.7bbc8cbb-3fc5-4586-8ab1-3981487d365c@github.com>
Message-ID: <8rdYmFhfDxFWQJPn2G5id0O7tmSwjkxMLrr3yGjAnjY=.666a7c07-4068-491b-891f-e74285ec1ffe@github.com>

On Fri, 7 Jul 2023 18:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>

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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
References: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
Message-ID: <-WEGyH-071rq9h_uuEeCHN1ZzwnDTptJqRI4jbaEHz8=.53f7e893-f6b9-46d7-862b-512e7e3413f5@github.com>

On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele <tsteele at openjdk.org> 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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
 <-WEGyH-071rq9h_uuEeCHN1ZzwnDTptJqRI4jbaEHz8=.53f7e893-f6b9-46d7-862b-512e7e3413f5@github.com>
Message-ID: <SAWZ15xktOhxnksuSvsfp2oBkYisRx3Ih4FCSocMzlk=.e6ef06ee-3e30-45e2-8f1b-2f8dfe72db84@github.com>

On Wed, 26 Jul 2023 07:42:50 GMT, Alan Bateman <alanb at openjdk.org> 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: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
References: <lAys-XyD8dCNJ0Sgokh3EmTcovTad3SdSn8pimO5YP0=.2057a275-5c4a-40c5-8337-e42f8883e362@github.com>
Message-ID: <sQTyEscjGRvqd88xfOY73SPyBYx1z88UAJe7XTvHeyw=.8d50d8fb-6835-4e3f-b3d5-a8e09c4a329c@github.com>

On Thu, 20 Jul 2023 18:11:15 GMT, Brian Burkhalter <bpb at openjdk.org> 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 <bpb at openjdk.org>
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: <cW2_M39HUU0rmxckswCjscydRcl4sOpUQr0oD2REkj4=.2c00a076-752b-49ef-b69c-41f39ba3f59c@github.com>

On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier <duke at openjdk.org> 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: <SQOKxeYiVVOx57iDZ0maH8jn9we0ZFdTR8lmGqElkh8=.d97e1aea-7b96-4481-a623-f6a5eb5b80e5@github.com>

On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier <duke at openjdk.org> 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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
References: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
Message-ID: <LP4y6-tX_61hlxadFnhkBSr31FTLzUxyfriuvo8QUWc=.05bcdb0e-f170-4b97-8a11-78a539d5e069@github.com>

On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele <tsteele at openjdk.org> 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: <kq4l05oHngGR8mJs1pWRjn5iNqPjoVnw9l_Vls0_KqE=.125a596d-d923-43cd-aa68-c2926e37f08a@github.com>

On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier <duke at openjdk.org> 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 <clanger at openjdk.org>
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: <zWRaaoeIDUklfqMbYKqKn1WI7FGhU--49eHtT9V-fYk=.4ff2acaa-6b14-45d4-b21e-cb721b12a9d4@github.com>

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: <zWRaaoeIDUklfqMbYKqKn1WI7FGhU--49eHtT9V-fYk=.4ff2acaa-6b14-45d4-b21e-cb721b12a9d4@github.com>
References: <zWRaaoeIDUklfqMbYKqKn1WI7FGhU--49eHtT9V-fYk=.4ff2acaa-6b14-45d4-b21e-cb721b12a9d4@github.com>
Message-ID: <lHTgyJgIZCDD24BDHjxE8sO8aJug_tkhYrCo-KL8cxw=.d5809d4c-2174-406f-9cd7-f2aa7db5851d@github.com>

On Thu, 27 Jul 2023 15:58:22 GMT, Christoph Langer <clanger at openjdk.org> 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: <zWRaaoeIDUklfqMbYKqKn1WI7FGhU--49eHtT9V-fYk=.4ff2acaa-6b14-45d4-b21e-cb721b12a9d4@github.com>
References: <zWRaaoeIDUklfqMbYKqKn1WI7FGhU--49eHtT9V-fYk=.4ff2acaa-6b14-45d4-b21e-cb721b12a9d4@github.com>
Message-ID: <0p9J5GP1xu1aAEJU1aFEeVEZ6Xbfie_lf1tZPIDExGg=.2ab59ea6-1e0b-42e3-a244-6931376c9e2a@github.com>

On Thu, 27 Jul 2023 15:58:22 GMT, Christoph Langer <clanger at openjdk.org> 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 <clanger at openjdk.org>
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: <lqXsGKp2X-pSIdaSfH7sLNbFx8IqlDPEmM9dGzKwHPA=.ffc73bef-c915-4d20-8b1e-06797328cd6f@github.com>

On Thu, 27 Jul 2023 14:38:20 GMT, Thomas Obermeier <duke at openjdk.org> 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: <lqXsGKp2X-pSIdaSfH7sLNbFx8IqlDPEmM9dGzKwHPA=.ffc73bef-c915-4d20-8b1e-06797328cd6f@github.com>
References: <7HwGQcAxTYxNke2sbmPg5iNAEM9TLi--XP4-Uvm8kjk=.cb173cb5-45f2-4079-9c0c-9233b97205aa@github.com>
 <lqXsGKp2X-pSIdaSfH7sLNbFx8IqlDPEmM9dGzKwHPA=.ffc73bef-c915-4d20-8b1e-06797328cd6f@github.com>
Message-ID: <3SSXLPc3H2EXrlL8nOug5MVwi0W5NIOIjUq6P3OvUVQ=.56222a29-4a4d-445d-b3cf-43f2ffc87ae4@github.com>

On Fri, 28 Jul 2023 09:56:10 GMT, Alan Bateman <alanb at openjdk.org> 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: <bLK0gM6BoxEn06e2DD-KY8L1kBNpiSQ-2ij9Aklafb0=.0b5fbc97-e90f-41d2-94f6-867f4afc6753@github.com>

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: <bLK0gM6BoxEn06e2DD-KY8L1kBNpiSQ-2ij9Aklafb0=.0b5fbc97-e90f-41d2-94f6-867f4afc6753@github.com>
References: <bLK0gM6BoxEn06e2DD-KY8L1kBNpiSQ-2ij9Aklafb0=.0b5fbc97-e90f-41d2-94f6-867f4afc6753@github.com>
Message-ID: <_lU82KgsqDOTsZTJeO7f9g0K6YtCEFinUaxsk68pTyM=.9c7642e5-55d3-4929-b335-472230bbff8b@github.com>

On Mon, 31 Jul 2023 18:16:49 GMT, Brian Burkhalter <bpb at openjdk.org> 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: <bLK0gM6BoxEn06e2DD-KY8L1kBNpiSQ-2ij9Aklafb0=.0b5fbc97-e90f-41d2-94f6-867f4afc6753@github.com>
References: <bLK0gM6BoxEn06e2DD-KY8L1kBNpiSQ-2ij9Aklafb0=.0b5fbc97-e90f-41d2-94f6-867f4afc6753@github.com>
Message-ID: <KbxsPF_r_fhC9LZIq6t8Y1hL99A7I9Y0to4wuRCplik=.becf0308-13a0-493b-9436-ad60db00ff85@github.com>

On Mon, 31 Jul 2023 18:16:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Reinstate header files so that `BLKGETSIZE64` is defined on Linux.

src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl.c line 52:

> 50: #include <sys/ioctl.h>
> 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: <LP4y6-tX_61hlxadFnhkBSr31FTLzUxyfriuvo8QUWc=.05bcdb0e-f170-4b97-8a11-78a539d5e069@github.com>
References: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
 <LP4y6-tX_61hlxadFnhkBSr31FTLzUxyfriuvo8QUWc=.05bcdb0e-f170-4b97-8a11-78a539d5e069@github.com>
Message-ID: <QJNVxKhyzaadV6dG2nshWEjlsLfdk8BgWk44OziupIc=.941d71c6-6142-43b5-804c-d98cbb42a2d7@github.com>

On Thu, 27 Jul 2023 15:10:31 GMT, Christoph Langer <clanger at openjdk.org> 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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
References: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
Message-ID: <LPoa2RuWxPtsPARNKagtK_Uuv-T3lO0ttL5rMHyQ7sM=.f9ab920f-24a9-4a5c-baac-30002136cf37@github.com>

> 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: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
References: <MPSBSN9kpgM27pv2tiMj0GbzdgjzkNefmSrzlDnuFh8=.0a1780a1-13e7-4c83-840c-63477b7a5049@github.com>
Message-ID: <VBZ7a3rESz0Yzg3P694-7rSqbkbbGsjUbkbT7Oml7QU=.0c586a12-d9cb-4e4a-8730-5fc5f44e8202@github.com>

On Thu, 20 Jul 2023 20:55:36 GMT, Tyler Steele <tsteele at openjdk.org> 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