From lancea at openjdk.java.net  Tue Dec  1 00:17:55 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 1 Dec 2020 00:17:55 GMT
Subject: Integrated: 8257445: (zipfs) Add DataProvider to
 TestLocOffsetFromZip64EF.java
In-Reply-To: <aSIv-eZr7OoS88szerzjjymrR2XWJlGvG73bUjFn-H0=.b409cd01-4eac-41e5-9c14-7941ebb11c06@github.com>
References: <aSIv-eZr7OoS88szerzjjymrR2XWJlGvG73bUjFn-H0=.b409cd01-4eac-41e5-9c14-7941ebb11c06@github.com>
Message-ID: <CuZQdfiojIjbqLFkznr5RSSz7FEAvG7QYK7GFKSC31g=.135c8337-7d41-4abe-9001-68ace6574ae0@github.com>

On Mon, 30 Nov 2020 21:59:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> HI all,
> 
> Please review this trivial change which adds a DataProvider to the manual test TestLocOffsetFromZip64EF.java, added as part of the fix for https://bugs.openjdk.java.net/browse/JDK-8255380,  to specify additional values for the  Zip FS file System property zipinfo-time.
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 11dad148
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11dad148
Stats:     21 lines in 1 file changed: 17 ins; 0 del; 4 mod

8257445: (zipfs) Add DataProvider to TestLocOffsetFromZip64EF.java

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/1527

From michaelm at openjdk.java.net  Wed Dec  9 11:48:46 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 9 Dec 2020 11:48:46 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
Message-ID: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>

Could I get the following small (temporary) test change reviewed please?

It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
Normal stderr, stdout is not available in that context.

Thanks,
Michael.

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

Commit messages:
 - add instrumentation to a test that has failed occasionally

Changes: https://git.openjdk.java.net/jdk/pull/1714/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257966
  Stats: 75 lines in 3 files changed: 37 ins; 11 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1714/head:pull/1714

PR: https://git.openjdk.java.net/jdk/pull/1714

From bpb at openjdk.java.net  Wed Dec  9 17:05:40 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 9 Dec 2020 17:05:40 GMT
Subject: RFR: 8257971: (fs) Remove unused code from WindowsPath.subpath(begin,
 end)
Message-ID: <cSCkKPK9XaQDSTVWCoSfMasbd5Qqu4iDP8ZdSMzDQVI=.6e05cca3-e765-4b52-882a-9d3679c9ffe6@github.com>

Please review this trivial change to remove the useless, vestigial local variable `nelems` from `WindowsPath::subpath(int,int)`.

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

Commit messages:
 - 8257971: (fs) Remove unused code from WindowsPath.subpath(begin, end)

Changes: https://git.openjdk.java.net/jdk/pull/1718/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1718&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257971
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1718/head:pull/1718

PR: https://git.openjdk.java.net/jdk/pull/1718

From lancea at openjdk.java.net  Wed Dec  9 17:18:33 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 9 Dec 2020 17:18:33 GMT
Subject: RFR: 8257971: (fs) Remove unused code from
 WindowsPath.subpath(begin, end)
In-Reply-To: <cSCkKPK9XaQDSTVWCoSfMasbd5Qqu4iDP8ZdSMzDQVI=.6e05cca3-e765-4b52-882a-9d3679c9ffe6@github.com>
References: <cSCkKPK9XaQDSTVWCoSfMasbd5Qqu4iDP8ZdSMzDQVI=.6e05cca3-e765-4b52-882a-9d3679c9ffe6@github.com>
Message-ID: <ZhAh7V77czpRPt8noARAA5MymXyi24Dd9GpW_hez494=.c1ffb0b9-25e4-4ffd-85fd-c993b580acf5@github.com>

On Wed, 9 Dec 2020 16:52:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this trivial change to remove the useless, vestigial local variable `nelems` from `WindowsPath::subpath(int,int)`.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1718

From chegar at openjdk.java.net  Thu Dec 10 09:48:35 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 10 Dec 2020 09:48:35 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
 <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>
Message-ID: <nkpF544xQjSTdHoDwDQjxYrFJ_CZTk0KuKJzOAS12og=.98bad397-790c-4c81-991f-31fed28ae512@github.com>

On Mon, 30 Nov 2020 20:54:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add explicitly allocated heap carrier buffer tests
>>  - Replace Single with Loop
>
> Marked as reviewed by bpb (Reviewer).

While the updated set of scenarios covered by this benchmark is
reasonably (and vastly improves coverage), I find myself reluctant to
add the last remaining buffer property - read-only views. It's time to
template the generation of this code!

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

PR: https://git.openjdk.java.net/jdk/pull/1430

From michaelm at openjdk.java.net  Thu Dec 10 12:00:49 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 12:00:49 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v2]
In-Reply-To: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
Message-ID: <dY3Uin1Qtr2f216daoLQJwKDBSpHx3ZUA-rNf0pZJnI=.6f2d5b74-71ee-4f2c-93f9-862746e0e639@github.com>

> Could I get the following small (temporary) test change reviewed please?
> 
> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
> Normal stderr, stdout is not available in that context.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:

 - updated and working, ready for review again
 - intermediate non functioning state

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1714/files
  - new: https://git.openjdk.java.net/jdk/pull/1714/files/90866ef0..342796b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=00-01

  Stats: 29 lines in 4 files changed: 13 ins; 1 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1714/head:pull/1714

PR: https://git.openjdk.java.net/jdk/pull/1714

From alanb at openjdk.java.net  Thu Dec 10 12:08:40 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 10 Dec 2020 12:08:40 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v2]
In-Reply-To: <dY3Uin1Qtr2f216daoLQJwKDBSpHx3ZUA-rNf0pZJnI=.6f2d5b74-71ee-4f2c-93f9-862746e0e639@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
 <dY3Uin1Qtr2f216daoLQJwKDBSpHx3ZUA-rNf0pZJnI=.6f2d5b74-71ee-4f2c-93f9-862746e0e639@github.com>
Message-ID: <vXQSjfAqOuHmxy_4xgFJpvq8-1H3NmphSxDWh_9Xo0M=.cfe460f7-fd9f-4c3c-b748-310d2234b45e@github.com>

On Thu, 10 Dec 2020 12:00:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following small (temporary) test change reviewed please?
>> 
>> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
>> Normal stderr, stdout is not available in that context.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated and working, ready for review again
>  - intermediate non functioning state

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java line 65:

> 63: 
> 64:     static String logDir;
> 65:     static PrintStream p;

Might be clear so you "ps" or "out" here rather than "p"

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java line 75:

> 73:         try {
> 74:             Path path = Path.of(logDir, "statetest.txt");
> 75:             FileOutputStream f = new FileOutputStream(path.toFile(), true);

This appends, is that intended? You could use Files.newOutputStream here to avoid the lossy conversion to File.

test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/java.policy.fail line 3:

> 1: //
> 2: //
> 3: //

Are the empty lines significant?

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

PR: https://git.openjdk.java.net/jdk/pull/1714

From michaelm at openjdk.java.net  Thu Dec 10 12:32:36 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 12:32:36 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v2]
In-Reply-To: <vXQSjfAqOuHmxy_4xgFJpvq8-1H3NmphSxDWh_9Xo0M=.cfe460f7-fd9f-4c3c-b748-310d2234b45e@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
 <dY3Uin1Qtr2f216daoLQJwKDBSpHx3ZUA-rNf0pZJnI=.6f2d5b74-71ee-4f2c-93f9-862746e0e639@github.com>
 <vXQSjfAqOuHmxy_4xgFJpvq8-1H3NmphSxDWh_9Xo0M=.cfe460f7-fd9f-4c3c-b748-310d2234b45e@github.com>
Message-ID: <8nttS4b9_lMxJHzIjJCEUI414mbVHcxiZ0dwr36WbQ0=.e1197a66-9ad3-4923-adbe-4d0ceb10cf83@github.com>

On Thu, 10 Dec 2020 12:04:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated and working, ready for review again
>>  - intermediate non functioning state
>
> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java line 75:
> 
>> 73:         try {
>> 74:             Path path = Path.of(logDir, "statetest.txt");
>> 75:             FileOutputStream f = new FileOutputStream(path.toFile(), true);
> 
> This appends, is that intended? You could use Files.newOutputStream here to avoid the lossy conversion to File.

Yes, there are multiple calls to StateTestService in the one test. So, they would be all overwritten by the last one. 

I had made the PR draft so I didn't realise there would be update notifications. But, thanks for the comments anyway. I will update and then re-open the review.

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

PR: https://git.openjdk.java.net/jdk/pull/1714

From michaelm at openjdk.java.net  Thu Dec 10 12:55:51 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 12:55:51 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v3]
In-Reply-To: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
Message-ID: <PoF_tO3phLAfZOxbaXGjOsuUDJ3s6LC9hf-oyBUurGI=.2fba5bf1-3b8d-4275-aadf-c2201688cf53@github.com>

> Could I get the following small (temporary) test change reviewed please?
> 
> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
> Normal stderr, stdout is not available in that context.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  after Alan's comments. Also removed extraneous delete action from permission file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1714/files
  - new: https://git.openjdk.java.net/jdk/pull/1714/files/342796b1..3676ae3a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=01-02

  Stats: 17 lines in 3 files changed: 5 ins; 5 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1714/head:pull/1714

PR: https://git.openjdk.java.net/jdk/pull/1714

From michaelm at openjdk.java.net  Thu Dec 10 12:55:52 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 12:55:52 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v2]
In-Reply-To: <vXQSjfAqOuHmxy_4xgFJpvq8-1H3NmphSxDWh_9Xo0M=.cfe460f7-fd9f-4c3c-b748-310d2234b45e@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
 <dY3Uin1Qtr2f216daoLQJwKDBSpHx3ZUA-rNf0pZJnI=.6f2d5b74-71ee-4f2c-93f9-862746e0e639@github.com>
 <vXQSjfAqOuHmxy_4xgFJpvq8-1H3NmphSxDWh_9Xo0M=.cfe460f7-fd9f-4c3c-b748-310d2234b45e@github.com>
Message-ID: <WSBPFmbG-s6FnexPz00T-4o-zqsSE7xxM2xkSmEj60o=.e33dcb7f-2bd6-495c-8b54-1df29033ebd2@github.com>

On Thu, 10 Dec 2020 12:05:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated and working, ready for review again
>>  - intermediate non functioning state
>
> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/java.policy.fail line 3:
> 
>> 1: //
>> 2: //
>> 3: //
> 
> Are the empty lines significant?

No. I've tidied that up. Was there before

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

PR: https://git.openjdk.java.net/jdk/pull/1714

From michaelm at openjdk.java.net  Thu Dec 10 13:10:48 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 13:10:48 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v4]
In-Reply-To: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
Message-ID: <d_s87LnQv7PGHTYB_PyiyqHjao-qcjIxM6b8X4RMpe8=.0df0f0f5-dd8d-4823-a880-efac90b132b3@github.com>

> Could I get the following small (temporary) test change reviewed please?
> 
> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
> Normal stderr, stdout is not available in that context.
> 
> Thanks,
> Michael.

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  removed unneeded import

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1714/files
  - new: https://git.openjdk.java.net/jdk/pull/1714/files/3676ae3a..85f689a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1714&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1714/head:pull/1714

PR: https://git.openjdk.java.net/jdk/pull/1714

From jvernee at openjdk.java.net  Thu Dec 10 14:04:35 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 10 Dec 2020 14:04:35 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <nkpF544xQjSTdHoDwDQjxYrFJ_CZTk0KuKJzOAS12og=.98bad397-790c-4c81-991f-31fed28ae512@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
 <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>
 <nkpF544xQjSTdHoDwDQjxYrFJ_CZTk0KuKJzOAS12og=.98bad397-790c-4c81-991f-31fed28ae512@github.com>
Message-ID: <5aRQdVf_tbxSwfbsvWMcqO_kBNTZ2m5RuZ6djoqGWQk=.a7c618fe-096f-43f9-b897-ba9ad4fd3dce@github.com>

On Thu, 10 Dec 2020 09:46:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Marked as reviewed by bpb (Reviewer).
>
> While the updated set of scenarios covered by this benchmark is
> reasonably (and vastly improves coverage), I find myself reluctant to
> add the last remaining buffer property - read-only views. It's time to
> template the generation of this code!

If the cases get to be too many, you might also want to consider splitting the benchmark class into several classes that cover different cases (we did this for the memory access benchmarks as well). That would also make it easier to run a subset of cases in isolation.

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

PR: https://git.openjdk.java.net/jdk/pull/1430

From alanb at openjdk.java.net  Thu Dec 10 14:46:37 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 10 Dec 2020 14:46:37 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v4]
In-Reply-To: <d_s87LnQv7PGHTYB_PyiyqHjao-qcjIxM6b8X4RMpe8=.0df0f0f5-dd8d-4823-a880-efac90b132b3@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
 <d_s87LnQv7PGHTYB_PyiyqHjao-qcjIxM6b8X4RMpe8=.0df0f0f5-dd8d-4823-a880-efac90b132b3@github.com>
Message-ID: <C3KhkiOVYZ5o09Z6GWQ38As-9HuaMAuOwhccpIEaOgo=.9a5f476a-5c4e-469a-a68e-6083c56ca8e4@github.com>

On Thu, 10 Dec 2020 13:10:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following small (temporary) test change reviewed please?
>> 
>> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
>> Normal stderr, stdout is not available in that context.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded import

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1714

From dfuchs at openjdk.java.net  Thu Dec 10 15:29:35 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 10 Dec 2020 15:29:35 GMT
Subject: RFR: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
 [v4]
In-Reply-To: <d_s87LnQv7PGHTYB_PyiyqHjao-qcjIxM6b8X4RMpe8=.0df0f0f5-dd8d-4823-a880-efac90b132b3@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
 <d_s87LnQv7PGHTYB_PyiyqHjao-qcjIxM6b8X4RMpe8=.0df0f0f5-dd8d-4823-a880-efac90b132b3@github.com>
Message-ID: <m3dNLKnE6cY9s5wLALEc6xHObA4w8W60nugYqdCLKco=.45735acf-8911-4355-aa9c-ccf5df082b19@github.com>

On Thu, 10 Dec 2020 13:10:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Could I get the following small (temporary) test change reviewed please?
>> 
>> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
>> Normal stderr, stdout is not available in that context.
>> 
>> Thanks,
>> Michael.
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unneeded import

This looks reasonable to me too. The only strange thing is having the log file in the `test.classes` directory, I would expect to have it in the `user.dir` instead (the scratch directory created by jtreg for the test, which is also the current working directory).

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1714

From michaelm at openjdk.java.net  Thu Dec 10 16:06:38 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Thu, 10 Dec 2020 16:06:38 GMT
Subject: Integrated: 8257966: Instrument
 test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java
In-Reply-To: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
References: <GLbD95l1shLzKn5WHTemxh0s8t50h6_oMW3kB1JNWwM=.df6d5c37-c242-4346-baa2-a9b1f24a8f01@github.com>
Message-ID: <Nyw96ELiWVAvGMZKhLShUvQV0ZgP_uyk6_a2dBTQqwQ=.92abdf2d-4c14-4722-9cb3-b67f896b888e@github.com>

On Wed, 9 Dec 2020 11:44:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Could I get the following small (temporary) test change reviewed please?
> 
> It adds some printlns to a file from a process launched by the inetd/launch simulator in the regression tests.
> Normal stderr, stdout is not available in that context.
> 
> Thanks,
> Michael.

This pull request has now been integrated.

Changeset: b35401d6
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b35401d6
Stats:     97 lines in 4 files changed: 52 ins; 15 del; 30 mod

8257966: Instrument test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/StateTestService.java

Reviewed-by: alanb, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/1714

From bpb at openjdk.java.net  Thu Dec 10 19:58:58 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 10 Dec 2020 19:58:58 GMT
Subject: Integrated: 8257971: (fs) Remove unused code from
 WindowsPath.subpath(begin, end)
In-Reply-To: <cSCkKPK9XaQDSTVWCoSfMasbd5Qqu4iDP8ZdSMzDQVI=.6e05cca3-e765-4b52-882a-9d3679c9ffe6@github.com>
References: <cSCkKPK9XaQDSTVWCoSfMasbd5Qqu4iDP8ZdSMzDQVI=.6e05cca3-e765-4b52-882a-9d3679c9ffe6@github.com>
Message-ID: <faUznmRAlFE7eIirPQFU5tOEamoxuhiAjinQs9rTJZI=.e372cc81-95f5-4946-8acf-1cca70a9948b@github.com>

On Wed, 9 Dec 2020 16:52:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this trivial change to remove the useless, vestigial local variable `nelems` from `WindowsPath::subpath(int,int)`.

This pull request has now been integrated.

Changeset: 42264b2d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42264b2d
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8257971: (fs) Remove unused code from WindowsPath.subpath(begin, end)

Reviewed-by: lancea

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

PR: https://git.openjdk.java.net/jdk/pull/1718

From philippe.marschall at gmail.com  Thu Dec 10 20:03:48 2020
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Thu, 10 Dec 2020 21:03:48 +0100
Subject: Optimization potential in Reader#read(CharBuffer)
Message-ID: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>

Hello

I recently came across Reader#read(CharBuffer) and noticed it was
missing an optimization for heap buffers. In the case of heap buffers
we can write directly into the backing array. Something like the
following

public int read(CharBuffer target) throws IOException {
    int len = target.remaining();
    int n;
    if (target.hasArray()) {
        char[] cbuf = target.array();
        int off = target.arrayOffset();
        n = this.read(cbuf, off, len);
    } else {
        char[] cbuf = new char[len];
        n = read(cbuf, 0, len);
        if (n > 0)
            target.put(cbuf, 0, n);
    }
    return n;
}

This would get rid of the intermediate allocation and copy in the case
of a heap buffer.

I don't have any microbenchmarks to prove this is faster but it seems intuitive.

Additionally there seem to be the following optimization potentials:

* The offheap path potentially allocates a very large, larger than
TRANSFER_BUFFER_SIZE, intermediate array. It may be worth considering
limiting the array size to TRANSFER_BUFFER_SIZE. Options are to use a
loop, this may require acquiring #lock to keep the read atomic, or
simply let the caller deal with it.
* It may be worth looking into overriding #read(CharBuffer) in
InputStreamReader and pass the CharBuffer to the StreamDecoder to
avoid more intermediate allocations and copies there.

Sorry if this is the wrong mailing list and should go to core-libs-dev
or a different list instead.

Cheers
Philippe

From brian.burkhalter at oracle.com  Thu Dec 10 20:23:07 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 10 Dec 2020 12:23:07 -0800
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
Message-ID: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>

Hi Philippe,

> On Dec 10, 2020, at 12:03 PM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
> 
> I recently came across Reader#read(CharBuffer) and noticed it was
> missing an optimization for heap buffers. [?]

These seem like good suggestions.

> Sorry if this is the wrong mailing list and should go to core-libs-dev
> or a different list instead.

I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there.

Do you have the ability to file an issue? If not, I can do so.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201210/57ae3b37/attachment.htm>

From pavel.rappo at oracle.com  Thu Dec 10 21:02:43 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 10 Dec 2020 21:02:43 +0000
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
Message-ID: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com>

I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314

> On 10 Dec 2020, at 20:23, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Philippe,
> 
>> On Dec 10, 2020, at 12:03 PM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>> 
>> I recently came across Reader#read(CharBuffer) and noticed it was
>> missing an optimization for heap buffers. [?]
> 
> These seem like good suggestions.
> 
>> Sorry if this is the wrong mailing list and should go to core-libs-dev
>> or a different list instead.
> 
> I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there.
> 
> Do you have the ability to file an issue? If not, I can do so.
> 
> Thanks,
> 
> Brian


From brian.burkhalter at oracle.com  Thu Dec 10 21:04:00 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 10 Dec 2020 13:04:00 -0800
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
 <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com>
Message-ID: <4CC9652C-424A-4FCD-B842-075D6F11DBA1@oracle.com>

Awesome, Pavel, thanks!

Brian

> On Dec 10, 2020, at 1:02 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314
> 
>> [?]
>> 
>> Do you have the ability to file an issue? If not, I can do so.

From philippe.marschall at gmail.com  Fri Dec 11 15:18:04 2020
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Fri, 11 Dec 2020 16:18:04 +0100
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
 <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com>
Message-ID: <CA+LFMPiXn0cvOcsevUZXzPCHuK+2vh6X21V+AJWkhikyQHPM_Q@mail.gmail.com>

Awesome, I'll work on a PR for this then.

Cheers
Philippe

On Thu, Dec 10, 2020 at 10:04 PM Pavel Rappo <pavel.rappo at oracle.com> wrote:
>
> I found this relevant issue created 17 years ago: https://bugs.openjdk.java.net/browse/JDK-4926314
>
> > On 10 Dec 2020, at 20:23, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> >
> > Hi Philippe,
> >
> >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
> >>
> >> I recently came across Reader#read(CharBuffer) and noticed it was
> >> missing an optimization for heap buffers. [?]
> >
> > These seem like good suggestions.
> >
> >> Sorry if this is the wrong mailing list and should go to core-libs-dev
> >> or a different list instead.
> >
> > I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there.
> >
> > Do you have the ability to file an issue? If not, I can do so.
> >
> > Thanks,
> >
> > Brian
>

From philippe.marschall at gmail.com  Fri Dec 11 16:31:30 2020
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Fri, 11 Dec 2020 17:31:30 +0100
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
Message-ID: <CA+LFMPh_mPpai=31VA9N-8p5P_f5PHRmkCjhbpS7fGrC89Jhag@mail.gmail.com>

On Thu, Dec 10, 2020 at 9:25 PM Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> Hi Philippe,
>
> On Dec 10, 2020, at 12:03 PM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
> ...
>
>
> I think that core-libs-dev (CCed) would be more appropriate as java.io package changes are usually discussed there.

Thank you.

> Do you have the ability to file an issue? If not, I can do so.

I don't have the ability to file an issue. The bug that Pavel found is
enough for me to work on for now. If you believe pursuing two other
improvements would be worthwhile I could work on them as well if you
file issues for them.

Cheers
Philippe

From brian.burkhalter at oracle.com  Fri Dec 11 16:35:00 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 11 Dec 2020 08:35:00 -0800
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <CA+LFMPh_mPpai=31VA9N-8p5P_f5PHRmkCjhbpS7fGrC89Jhag@mail.gmail.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
 <CA+LFMPh_mPpai=31VA9N-8p5P_f5PHRmkCjhbpS7fGrC89Jhag@mail.gmail.com>
Message-ID: <C35535D8-57AB-4C46-B8F8-BED499685744@oracle.com>

Hello,

> On Dec 11, 2020, at 8:31 AM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
> 
>> Do you have the ability to file an issue? If not, I can do so.
> 
> I don't have the ability to file an issue. The bug that Pavel found is
> enough for me to work on for now. If you believe pursuing two other
> improvements would be worthwhile I could work on them as well if you
> file issues for them.

I think perhaps they could all go in the same PR as the things are quite related. It would be good to have simple JMH benchmarks to measure the improvements. The benchmark code does not necessarily have to be in the PR, i.e., checked in.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201211/14fccb38/attachment.htm>

From sormuras at gmail.com  Fri Dec 11 20:51:46 2020
From: sormuras at gmail.com (Christian Stein)
Date: Fri, 11 Dec 2020 21:51:46 +0100
Subject: [JDK-7133447] OSX optimized WatchService
Message-ID: <CAJi8+g7GvCxMqJWe7Z5UwKos73KpcLZzR05TFRfDQy0s4ENBkg@mail.gmail.com>

// Posting on behalf of Andres Almiray

Hello everyone,
At the Layrry project we encountered this particular issue while trying to
shed external dependencies and rely on as many JDK-only APIs as possible.

Specifically the OSX WatchService from
https://github.com/gmethvin/directory-watcher is capable of reacting to
directory changes much faster (almost instantaneously at least to the naked
eye) than the OSX WatchService provided by OpenJDK (which takes a couple of
seconds to react, very noticeable).

https://bugs.openjdk.java.net/browse/JDK-7133447 was created close to 9
years ago and no updates have been posted since.
Unfortunately I don?t have any experience with code required to provide a
patch but I?m willing to help testing out any patches and/or with other
tasks that can bring this ticket to a fruitful solution.

Cheers,
Andres
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201211/18139fea/attachment.htm>

From brian.burkhalter at oracle.com  Fri Dec 11 21:01:54 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 11 Dec 2020 13:01:54 -0800
Subject: [JDK-7133447] OSX optimized WatchService
In-Reply-To: <CAJi8+g7GvCxMqJWe7Z5UwKos73KpcLZzR05TFRfDQy0s4ENBkg@mail.gmail.com>
References: <CAJi8+g7GvCxMqJWe7Z5UwKos73KpcLZzR05TFRfDQy0s4ENBkg@mail.gmail.com>
Message-ID: <53123F70-6149-4C83-AC75-05C232FF4557@oracle.com>

Hello Andres / Christian,

> On Dec 11, 2020, at 12:51 PM, Christian Stein <sormuras at gmail.com> wrote:
> 
> // Posting on behalf of Andres Almiray
> 
> Hello everyone,
> At the Layrry project we encountered this particular issue while trying to shed external dependencies and rely on as many JDK-only APIs as possible.
> 
> Specifically the OSX WatchService from https://github.com/gmethvin/directory-watcher <https://github.com/gmethvin/directory-watcher> is capable of reacting to directory changes much faster (almost instantaneously at least to the naked eye) than the OSX WatchService provided by OpenJDK (which takes a couple of seconds to react, very noticeable).

Yes the extant WatchService on macOS is based on polling and is relatively slow.

> https://bugs.openjdk.java.net/browse/JDK-7133447 <https://bugs.openjdk.java.net/browse/JDK-7133447> was created close to 9 years ago and no updates have been posted since.

I spent some time trying to solve this one using Kqueues but so far did not succeed in fixing it. I am not sure whether that approach can work.

> Unfortunately I don?t have any experience with code required to provide a patch but I?m willing to help testing out any patches and/or with other tasks that can bring this ticket to a fruitful solution.

Are you suggesting making a contribution to fix this, or simply validating a solution we come up with? If the former, that would be most welcome provided it can be done under the conditions require, e.g., signed OCA, etc., but that seems already to be in place.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201211/45b315ba/attachment-0001.htm>

From brian.burkhalter at oracle.com  Mon Dec 14 17:38:30 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 14 Dec 2020 09:38:30 -0800
Subject: [JDK-7133447] OSX optimized WatchService
In-Reply-To: <1211933706.6047590.1607767164347@mail.yahoo.com>
References: <CAJi8+g7GvCxMqJWe7Z5UwKos73KpcLZzR05TFRfDQy0s4ENBkg@mail.gmail.com>
 <53123F70-6149-4C83-AC75-05C232FF4557@oracle.com>
 <1211933706.6047590.1607767164347@mail.yahoo.com>
Message-ID: <6798244F-D2B8-469F-873A-DCF7969FC091@oracle.com>

Hi Andres,

> On Dec 12, 2020, at 1:59 AM, Almiray <aalmiray at yahoo.com> wrote:
> 
> I'd love to help with this issue, but as mentioned earlier I do not have the expertise to provide a patch on my own.

Well with any luck we can come up with something for you to test eventually.

> Also, unfortunately the code from https://github.com/gmethvin/directory-watcher <https://urldefense.com/v3/__https://github.com/gmethvin/directory-watcher__;!!GqivPVa7Brio!LmBgW7wuoFZOx5cuxL5QWWvCqMBp9NN6pvfybWkyLlgUnB5LSMP6Gwt4azpam-jYQf2c$> cannot be used "as is" given that
> 
> - it's Apache 2 licensed and OpenJDK is GPL.
> - it relies on JNA, I bet there are other alternatives in OpenJDK to deal with native calls.

Yes, that would make it unusable. I did not look at the code.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201214/1d08e74d/attachment.htm>

From philippe.marschall at gmail.com  Mon Dec 14 19:31:46 2020
From: philippe.marschall at gmail.com (Philippe Marschall)
Date: Mon, 14 Dec 2020 20:31:46 +0100
Subject: Optimization potential in Reader#read(CharBuffer)
In-Reply-To: <C35535D8-57AB-4C46-B8F8-BED499685744@oracle.com>
References: <CA+LFMPiw2_-oP2qqTDekJ+DEwkF7zcNzFnhUU=0K7+3w5ZYQ3g@mail.gmail.com>
 <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com>
 <CA+LFMPh_mPpai=31VA9N-8p5P_f5PHRmkCjhbpS7fGrC89Jhag@mail.gmail.com>
 <C35535D8-57AB-4C46-B8F8-BED499685744@oracle.com>
Message-ID: <CA+LFMPj-M5xjtAkVbA3tFgs46A_rk8T-rO+0h=nAFzGcZRFkFA@mail.gmail.com>

On Fri, Dec 11, 2020 at 5:35 PM Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
>
> Hello,
>
> ...
>
>
> I think perhaps they could all go in the same PR as the things are quite related. It would be good to have simple JMH benchmarks to measure the improvements. The benchmark code does not necessarily have to be in the PR, i.e., checked in.
>

That works for me.

Philippe

From bchristi at openjdk.java.net  Mon Dec 14 19:41:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 14 Dec 2020 19:41:05 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
Message-ID: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>

This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).

Here are the changes covering core libraries code and tests.  Terms were changed as follows:
1. grandfathered -> legacy
2. blacklist -> filter or reject
3. whitelist -> allow or accept
4. master -> coordinator
5. slave -> worker

Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

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

Commit messages:
 - Terminology Cleanup
 - corelibs terminology refresh - bchristi

Changes: https://git.openjdk.java.net/jdk/pull/1771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253497
  Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771

From naoto at openjdk.java.net  Mon Dec 14 20:29:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Dec 2020 20:29:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <6mGHyzJFxdntyaLG6CFPBw87a3I7caQuhWGz8hpLneY=.44f01fb2-a150-42e6-a3b0-853d72d24a1b@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Looks good to me.

test/jdk/java/lang/ClassLoader/Assert.java line 65:

> 63: 
> 64:         int switchSource = 0;
> 65:         if (args.length == 0) { // This is  the coordinator version

Extra space between "is" and "the."

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1771

From kcr at openjdk.java.net  Mon Dec 14 20:38:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 14 Dec 2020 20:38:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <ucR9bOGxWzSMGwDy9XYG_xjlDnob_wMLOoksGUE9Xu0=.328ad058-1764-48ca-93ae-9605de0e7aa6@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From joehw at openjdk.java.net  Mon Dec 14 21:15:58 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 14 Dec 2020 21:15:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by joehw (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135:

> 133:      * The pattern must be in same format as used in
> 134:      * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135:      * It may define an accept-list of permitted classes, a reject-list of

should accept-list be allow-list to be consistent with the other two RMI classes and ObjectInputFilter.Status#ALLOWED?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:

> 150:      * <p>
> 151:      * Care must be taken when defining such a filter, as defining
> 152:      * an accept-list too restrictive or a too-wide reject-list may

would "an allow-list too restrictive or a reject-list too wide" read better?

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From rriggs at openjdk.java.net  Mon Dec 14 21:15:56 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 14 Dec 2020 21:15:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <K0seMjLKhhmowZfX2kKeybGzSUvezMw5u96B2QtC-Us=.52ca831d-8036-4fc5-9fe0-f3ce0bf9160c@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Marked as reviewed by rriggs (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 135:

> 133:      * The pattern must be in same format as used in
> 134:      * {@link java.io.ObjectInputFilter.Config#createFilter}.
> 135:      * It may define an accept-list of permitted classes, a reject-list of

accept -> allow for consistency

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:

> 150:      * <p>
> 151:      * Care must be taken when defining such a filter, as defining
> 152:      * an accept-list too restrictive or a too-wide reject-list may

accept -> allow for consistency

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 01:38:59 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 01:38:59 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh
In-Reply-To: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
Message-ID: <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>

On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:
> 
>> 150:      * <p>
>> 151:      * Care must be taken when defining such a filter, as defining
>> 152:      * an accept-list too restrictive or a too-wide reject-list may
> 
> would "an allow-list too restrictive or a reject-list too wide" read better?

I agree that there is room for improvement here.  How about:
"...an allow-list too restrictively, or a reject-list too broadly, may..."
?

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 01:46:08 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 01:46:08 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  updates, per code review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1771/files
  - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771

From joehw at openjdk.java.net  Tue Dec 15 01:46:09 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 15 Dec 2020 01:46:09 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
 <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
Message-ID: <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>

On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152:
>> 
>>> 150:      * <p>
>>> 151:      * Care must be taken when defining such a filter, as defining
>>> 152:      * an accept-list too restrictive or a too-wide reject-list may
>> 
>> would "an allow-list too restrictive or a reject-list too wide" read better?
>
> I agree that there is room for improvement here.  How about:
> "...an allow-list too restrictively, or a reject-list too broadly, may..."
> ?

That sounds good to me

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From brett.okken.os at gmail.com  Tue Dec 15 02:22:36 2020
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 14 Dec 2020 20:22:36 -0600
Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer memory
Message-ID: <CANBJVOHxxA9J4sv25z1ufuYqNmFJeTMECHTMsHGEGgOpS6EJvA@mail.gmail.com>

 I am not sure if this is the correct mailing list for this question.
Please let me know if I should post it somewhere else.

The javadoc for SoftReference states:

All soft references to softly-reachable objects are guaranteed to have been
cleared before the virtual machine throws an OutOfMemoryError.

But that is not quite true when it comes to allocating direct ByteBuffer
instances. Would it be possible to clear softly-reachable direct ByteBuffer
instances prior to throwing java.lang.OutOfMemoryError: Direct buffer
memory? This would make it much simpler (and safer) to implement a cache of
direct ByteBuffer instances for re-use.

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201214/984ec520/attachment.htm>

From alanb at openjdk.java.net  Tue Dec 15 07:36:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Dec 2020 07:36:57 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
Message-ID: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com>

On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per code review

test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45:

> 43:         SocketChannel client = SocketChannel.open ();
> 44:         client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port));
> 45:         SocketChannel channel = server.accept ();

Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From ihse at openjdk.java.net  Tue Dec 15 09:19:56 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:19:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
 <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
 <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>
Message-ID: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com>

On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> I agree that there is room for improvement here.  How about:
>> "...an allow-list too restrictively, or a reject-list too broadly, may..."
>> ?
>
> Your call, I'm not a native English speaker :-)  It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list.

It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 18:50:56 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 18:50:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
 <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com>
Message-ID: <8p4RRf4ltO4wlaOuBRdmlMA-EFGqomUwl2Oat9RwOzw=.95ea6210-d252-4d7a-b316-0384c14b4490@github.com>

On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates, per code review
>
> test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45:
> 
>> 43:         SocketChannel client = SocketChannel.open ();
>> 44:         client.connect (new InetSocketAddress (InetAddress.getLoopbackAddress(), port));
>> 45:         SocketChannel channel = server.accept ();
> 
> Can you rename this to "peer" instead? (we can remove the spurious space after accept while we are there).

Yes, I will name it, "peer", and remove the extra space on the affected lines.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>

On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

I believe this changes is useful and still actual:
1. improve code to make it easier to read.
2. performance should be improved a bit too

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before instanceof
 check in java.base
Message-ID: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>

8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Commit messages:
 - [PATCH] Cleanup unnecessary null comparison before instanceof check in java.base

Changes: https://git.openjdk.java.net/jdk/pull/20/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258422
  Stats: 42 lines in 21 files changed: 0 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From chegar at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
Message-ID: <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>

On Sat, 31 Oct 2020 19:37:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I believe this changes is useful and still actual:
>> 1. improve code to make it easier to read.
>> 2. performance should be improved a bit too
>
> I?ll see if I can get somebody to take a look at this.

This seems like a reasonable change, which improves readability.

My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -2191,8 +2191,8 @@ public class File
      *          {@code false} otherwise
      */
     public boolean equals(Object obj) {
-        if ((obj != null) && (obj instanceof File)) {
-            return compareTo((File)obj) == 0;
+        if (obj instanceof File file) {
+            return compareTo(file) == 0;
         }
         return false;
     }

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

PR: https://git.openjdk.java.net/jdk/pull/20

From smarks at openjdk.java.net  Tue Dec 15 18:58:06 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 15 Dec 2020 18:58:06 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
Message-ID: <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>

On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> I believe this changes is useful and still actual:
> 1. improve code to make it easier to read.
> 2. performance should be improved a bit too

I?ll see if I can get somebody to take a look at this.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
 <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
Message-ID: <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>

On Mon, 2 Nov 2020 09:15:31 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> I?ll see if I can get somebody to take a look at this.
>
> This seems like a reasonable change, which improves readability.
> 
> My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -2191,8 +2191,8 @@ public class File
>       *          {@code false} otherwise
>       */
>      public boolean equals(Object obj) {
> -        if ((obj != null) && (obj instanceof File)) {
> -            return compareTo((File)obj) == 0;
> +        if (obj instanceof File file) {
> +            return compareTo(file) == 0;
>          }
>          return false;
>      }

Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448

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

PR: https://git.openjdk.java.net/jdk/pull/20

From aefimov at openjdk.java.net  Tue Dec 15 18:58:07 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 15 Dec 2020 18:58:07 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base
In-Reply-To: <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <KRgmC9C2Vm5F1Fo7mWvfWaYhWw9I-6S1_iojQ3F6NjA=.0b349063-4867-4832-a603-ad49fb81ac25@github.com>
 <vrsyEJL3Gi3TT-i_XdZ1PD5kX-0dsbCVP2mjCOhSyt4=.bb6703bb-d272-4047-83a2-90a5f9641a6f@github.com>
 <UWm_PGPQmwlamBFb5bS3hMRRMdunaohchm8C3ZRqb98=.5a724cbb-32c3-44da-87b5-9008705b4c8c@github.com>
 <g-aCzpKxvmY6YXcXhfoeSyKB_drLyHTlxWpVKjUJzVs=.3ca67a6e-93a9-48cb-99fd-9e3820eeb7b5@github.com>
Message-ID: <CUAgVMeEaogYo63HvIEQ8toOHSTHrirp-dG8jPXzLf0=.3e82b0b1-e38f-44e5-9ee4-75faee04ac24@github.com>

On Wed, 2 Dec 2020 20:15:02 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This seems like a reasonable change, which improves readability.
>> 
>> My preference is to wait a little longer (hopefully no more than a couple of weeks), until [JEP 394](https://openjdk.java.net/jeps/394) - "Pattern Matching for instanceof" is finalised, then we can remove the explicit casts in many of these cases. For example:
>> 
>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -2191,8 +2191,8 @@ public class File
>>       *          {@code false} otherwise
>>       */
>>      public boolean equals(Object obj) {
>> -        if ((obj != null) && (obj instanceof File)) {
>> -            return compareTo((File)obj) == 0;
>> +        if (obj instanceof File file) {
>> +            return compareTo(file) == 0;
>>          }
>>          return false;
>>      }
>
> Related issue - https://bugs.openjdk.java.net/browse/JDK-8257448

Hi @turbanoff,

I've logged a JBS issue for tracking this change:
https://bugs.openjdk.java.net/browse/JDK-8258422

JEP 394 is finalized now, so I guess you could follow-up Chris suggestion to remove the explicit casts.

After the fix is properly reviewed and marked as ready for the integration (you'll need to issue `/integrate` command), once it is done I would happily `/sponsor` the change.

With Best Regards,
Aleksei

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 15 19:52:31 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 15 Dec 2020 19:52:31 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v2]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
   use instanceof pattern matching
 - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/f09bbd24..603cd364

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=00-01

  Stats: 784681 lines in 7664 files changed: 596718 ins; 128884 del; 59079 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From bpb at openjdk.java.net  Tue Dec 15 22:00:05 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 15 Dec 2020 22:00:05 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
Message-ID: <AP8NPSJB6yGOkKwlngzueZXQNWRsCX4Lrt1vrt5ah7s=.1d742545-f9fc-47f0-bca8-e215fd4510a3@github.com>

On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates, per code review

test/jdk/java/lang/ClassLoader/Assert.java line 65:

> 63: 
> 64:         int switchSource = 0;
> 65:         if (args.length == 0) { // This is the coordinator version

Perhaps s/coordinator/controller/?

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From lancea at openjdk.java.net  Tue Dec 15 22:04:59 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 15 Dec 2020 22:04:59 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <AP8NPSJB6yGOkKwlngzueZXQNWRsCX4Lrt1vrt5ah7s=.1d742545-f9fc-47f0-bca8-e215fd4510a3@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
 <AP8NPSJB6yGOkKwlngzueZXQNWRsCX4Lrt1vrt5ah7s=.1d742545-f9fc-47f0-bca8-e215fd4510a3@github.com>
Message-ID: <lU3j1evUF7FtehkVSeaeiVDKrK8bWb2Q3AINxBnN35s=.407a29f7-a0fd-43ac-9864-7bd1487af545@github.com>

On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates, per code review
>
> test/jdk/java/lang/ClassLoader/Assert.java line 65:
> 
>> 63: 
>> 64:         int switchSource = 0;
>> 65:         if (args.length == 0) { // This is the coordinator version
> 
> Perhaps s/coordinator/controller/?

Let's change it to: 

// This is the controller

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 22:05:00 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 22:05:00 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <lU3j1evUF7FtehkVSeaeiVDKrK8bWb2Q3AINxBnN35s=.407a29f7-a0fd-43ac-9864-7bd1487af545@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <gvGudpAHznlo-2b2W2a0dxtgDX3Ws6Lq_9-Q2D65Zmo=.2cdb68d7-5d25-4b68-90e5-2444a2ce7adb@github.com>
 <AP8NPSJB6yGOkKwlngzueZXQNWRsCX4Lrt1vrt5ah7s=.1d742545-f9fc-47f0-bca8-e215fd4510a3@github.com>
 <lU3j1evUF7FtehkVSeaeiVDKrK8bWb2Q3AINxBnN35s=.407a29f7-a0fd-43ac-9864-7bd1487af545@github.com>
Message-ID: <DixdPSfjNXoAXjFMzfNI6iRa7BbNOLoQCckDtqnryWU=.de23933e-32d2-433a-ae6c-ae4b937e918f@github.com>

On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> test/jdk/java/lang/ClassLoader/Assert.java line 65:
>> 
>>> 63: 
>>> 64:         int switchSource = 0;
>>> 65:         if (args.length == 0) { // This is the coordinator version
>> 
>> Perhaps s/coordinator/controller/?
>
> Let's change it to: 
> 
> // This is the controller

Will do.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From smarks at openjdk.java.net  Tue Dec 15 22:16:57 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 15 Dec 2020 22:16:57 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v2]
In-Reply-To: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
 <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
 <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>
 <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com>
Message-ID: <PyLAAK64lq7vFe4t4X_NSwXfg3piCq69KvUQZNFmmvg=.b8f00bd3-70ad-40ac-8deb-fadaa60b88c8@github.com>

On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Your call, I'm not a native English speaker :-)  It felt to me it's 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a restrictive allow-list.
>
> It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former.

I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too-wide may prevent ...`.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 22:21:12 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 22:21:12 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v3]
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <cFd-StKSZN3OLzli4GiTY-h0Q-1i4T6fpKUmXE49cvk=.ca841417-510b-47ae-9710-5bfc4bdcaef4@github.com>

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Brent Christian has updated the pull request incrementally with three additional commits since the last revision:

 - This is the controller
 - use 'controller' in Assert.java
 - use 'peer' in CloseRegisteredChannel.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1771/files
  - new: https://git.openjdk.java.net/jdk/pull/1771/files/29525f05..b8cd8b6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771

From bpb at openjdk.java.net  Tue Dec 15 22:46:59 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 15 Dec 2020 22:46:59 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v3]
In-Reply-To: <cFd-StKSZN3OLzli4GiTY-h0Q-1i4T6fpKUmXE49cvk=.ca841417-510b-47ae-9710-5bfc4bdcaef4@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <cFd-StKSZN3OLzli4GiTY-h0Q-1i4T6fpKUmXE49cvk=.ca841417-510b-47ae-9710-5bfc4bdcaef4@github.com>
Message-ID: <e88mdnB1oPR5l7rUi6IcfOhc0rhFmRtobpMDjnYpY_k=.99332134-9e45-4040-abb8-3e16d1e8bd6c@github.com>

On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - This is the controller
>  - use 'controller' in Assert.java
>  - use 'peer' in CloseRegisteredChannel.java

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From rriggs at openjdk.java.net  Tue Dec 15 22:46:58 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 15 Dec 2020 22:46:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v3]
In-Reply-To: <cFd-StKSZN3OLzli4GiTY-h0Q-1i4T6fpKUmXE49cvk=.ca841417-510b-47ae-9710-5bfc4bdcaef4@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <cFd-StKSZN3OLzli4GiTY-h0Q-1i4T6fpKUmXE49cvk=.ca841417-510b-47ae-9710-5bfc4bdcaef4@github.com>
Message-ID: <AWElw-dsAxq_LvaeyNvTfiCViBf298Zx-vLakIYoSn0=.ae305bb0-5a63-404f-8363-2465da38627f@github.com>

On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - This is the controller
>  - use 'controller' in Assert.java
>  - use 'peer' in CloseRegisteredChannel.java

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 23:09:55 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 23:09:55 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v3]
In-Reply-To: <PyLAAK64lq7vFe4t4X_NSwXfg3piCq69KvUQZNFmmvg=.b8f00bd3-70ad-40ac-8deb-fadaa60b88c8@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com>
 <BmzALdZWNiH3LMJ2xUOHNcLdU6kEu0GRkktPpo2BkII=.f5136170-5d4f-4ee5-8c37-2454916938a6@github.com>
 <TZV1N7mk13QAb8casXllkVpuft3iExT_ISM3QYutRh8=.b168d39b-e786-4b14-b9dd-c742ad073b7a@github.com>
 <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com>
 <PyLAAK64lq7vFe4t4X_NSwXfg3piCq69KvUQZNFmmvg=.b8f00bd3-70ad-40ac-8deb-fadaa60b88c8@github.com>
Message-ID: <YhamnqlvGjeHCQphbMzf8m7zznb6ZLv1BOquII5ymac=.ed3985e2-8cb6-4eae-b6f0-5bde8d65bc63@github.com>

On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> It's an adverb, since it's the act of 'defining' that is being done too restrictively or broadly. If you want to have an adjective you would need to rephrase it so it applies to the noun, like 'defining a too restrictive accept-list'. My non-native English vibes would still prefer the former.
>
> I'd suggest `... as defining an allow-list that is too narrow or a reject-list that is too wide may prevent ...`.
> 
> (edited to remove hyphen from "too-wide")

Even better!

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Tue Dec 15 23:14:14 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 15 Dec 2020 23:14:14 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v4]
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  improve SERIAL_FILTER_PATTERN comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1771/files
  - new: https://git.openjdk.java.net/jdk/pull/1771/files/b8cd8b6d..ba586413

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771

From smarks at openjdk.java.net  Tue Dec 15 23:36:58 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 15 Dec 2020 23:36:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v4]
In-Reply-To: <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>
Message-ID: <C46xXPgVdcqMIwz0gqhRZUe0WmGX44f7kLTY1CYMXwg=.bfa0f5c1-a091-4c4f-863a-f2031847a5b5@github.com>

On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve SERIAL_FILTER_PATTERN comment

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From alanb at openjdk.java.net  Wed Dec 16 07:13:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 07:13:58 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v4]
In-Reply-To: <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>
Message-ID: <F-rpAlhTfXxB85ATNs9d20d4LHw0OCgcI3zCFJ_xmTk=.fb0827e5-690c-4ea8-bcea-6c3690481652@github.com>

On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve SERIAL_FILTER_PATTERN comment

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/util/Locale.java line 1649:

> 1647:      * <p>This implements the 'Language-Tag' production of BCP47, and
> 1648:      * so supports legacy (regular and irregular, referred to as
> 1649:      * {@code Type: grandfathered} in BCP47) as well as

You might consider putting quotes around "Type; grandfathered" here, otherwise looks good.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From alanb at openjdk.java.net  Wed Dec 16 07:16:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 07:16:00 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v2]
In-Reply-To: <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <VvXTa0Ddr89TMa3WRNmF1Tr_NxGJNaXVWFSEAq19nMI=.a1beff5f-0e4e-4309-b0f6-723075bc3d1a@github.com>
Message-ID: <_LvzyyCLPoXsNJNNlU_qBmje3U5RvwKifXod1bN5Yc8=.b11b4f6e-16e0-4f92-a052-b55dc2fecb33@github.com>

On Tue, 15 Dec 2020 19:52:31 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>    use instanceof pattern matching
>  - 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

src/java.base/windows/classes/sun/nio/fs/WindowsPath.java line 803:

> 801:         if (obj instanceof WindowsPath path) {
> 802:             return compareTo(path) == 0;
> 803:         }

Can you do the same in UnixPath?

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 09:20:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 09:20:09 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  use instanceof pattern matching in UnixPath too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/603cd364..0d2ac405

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From chegar at openjdk.java.net  Wed Dec 16 09:47:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 16 Dec 2020 09:47:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
Message-ID: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>

On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   use instanceof pattern matching in UnixPath too

Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.

src/java.base/share/classes/java/net/InetSocketAddress.java line 414:

> 412:         if (!(obj instanceof InetSocketAddress))
> 413:             return false;
> 414:         return holder.equals(((InetSocketAddress) obj).holder);

If we restructure this a little we can get:

    public final boolean equals(Object obj) {
        if (obj instanceof InetSocketAddress that)
            return holder.equals(that.holder);
        return false;
    }

src/java.base/share/classes/java/net/InetSocketAddress.java line 124:

> 122:             if (!(obj instanceof InetSocketAddressHolder))
> 123:                 return false;
> 124:             InetSocketAddressHolder that = (InetSocketAddressHolder)obj;

If we restructure this a little we can take advantage of flow scoping, e.g.

 public final boolean equals(Object obj) {
            if (!(obj instanceof InetSocketAddressHolder that))
                return false;
            boolean sameIP;
            if (addr != null)
                sameIP = addr.equals(that.addr);
            else if (hostname != null)
                sameIP = (that.addr == null) &&
                    hostname.equalsIgnoreCase(that.hostname);
            else
                sameIP = (that.addr == null) && (that.hostname == null);
            return sameIP && (port == that.port);
        }

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

Changes requested by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 10:32:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 10:32:12 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  take advantage of "flow scoping" to eliminate casts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/0d2ac405..f5727ca9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=02-03

  Stats: 42 lines in 12 files changed: 1 ins; 10 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From aefimov at openjdk.java.net  Wed Dec 16 18:29:56 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 16 Dec 2020 18:29:56 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
Message-ID: <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>

On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   use instanceof pattern matching in UnixPath too
>
> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.

Hi Andrey,

Could you, please, also take a look at `java.net.Socket`:
java/net/Socket.java:        if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress)))
java/net/Socket.java-            throw new IllegalArgumentException("Unsupported address type");
And `HttpURLConnection`:
    sun/net/www/protocol/http/HttpURLConnection.java:                    if (a != null && c instanceof HttpURLConnection) {
    sun/net/www/protocol/http/HttpURLConnection.java-                        ((HttpURLConnection)c).setAuthenticator(a);
The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "`

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec 16 19:22:01 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 16 Dec 2020 19:22:01 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
 <DGiyYlNMra_BwddNuNJjqkwQDTlJn-G3kYM0kXKI940=.b13e3c95-9c7d-4070-9d4b-8be836c8d17a@github.com>
Message-ID: <PsCRfKfKNe5DhzumlSgAd_iFi0Zh1lcd45OoG3ztd28=.2f611fd2-ee81-4709-865d-40022a86659d@github.com>

On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.
>
> Hi Andrey,
> 
> Could you, please, also take a look at `java.net.Socket`:
> java/net/Socket.java:        if (bindpoint != null && (!(bindpoint instanceof InetSocketAddress)))
> java/net/Socket.java-            throw new IllegalArgumentException("Unsupported address type");
> And `HttpURLConnection`:
>     sun/net/www/protocol/http/HttpURLConnection.java:                    if (a != null && c instanceof HttpURLConnection) {
>     sun/net/www/protocol/http/HttpURLConnection.java-                        ((HttpURLConnection)c).setAuthenticator(a);
> The following cmd was used to find them: `rgrep -A 1 "= null .* instanceof "`

@AlekseiEfimov in both cases removing `null` check will change semantic of the code. Comparison is not redundant.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From bchristi at openjdk.java.net  Wed Dec 16 20:00:59 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 16 Dec 2020 20:00:59 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v4]
In-Reply-To: <F-rpAlhTfXxB85ATNs9d20d4LHw0OCgcI3zCFJ_xmTk=.fb0827e5-690c-4ea8-bcea-6c3690481652@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <AclI3mrK8jFmyiN-6zMuX3DWCZ45M_WfiJizKNyOl44=.d0538c9c-8b32-44e7-a8d4-a179ab0b5cad@github.com>
 <F-rpAlhTfXxB85ATNs9d20d4LHw0OCgcI3zCFJ_xmTk=.fb0827e5-690c-4ea8-bcea-6c3690481652@github.com>
Message-ID: <_3eyagnLPeaqOmlVW65dLaW-Wml-BqQHSAtqFGgtzcE=.1168634c-3ed4-457a-867c-5d8bcd0d12c1@github.com>

On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve SERIAL_FILTER_PATTERN comment
>
> src/java.base/share/classes/java/util/Locale.java line 1649:
> 
>> 1647:      * <p>This implements the 'Language-Tag' production of BCP47, and
>> 1648:      * so supports legacy (regular and irregular, referred to as
>> 1649:      * {@code Type: grandfathered} in BCP47) as well as
> 
> You might consider putting quotes around "Type; grandfathered" here, otherwise looks good.

Yes, having that in quotes instead of in {@code} would be consistent with the rest of Locale.java.  I will change that.

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Wed Dec 16 20:08:11 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 16 Dec 2020 20:08:11 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v5]
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <YtcsLXC3RyluT0sdpQPKNnU3hFe3v8gnEC1hB00hHhI=.949b851d-5e2a-4e61-a83e-f13cb0afa1ec@github.com>

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Use quotes instead of @code in Locale

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1771/files
  - new: https://git.openjdk.java.net/jdk/pull/1771/files/ba586413..03264330

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771

PR: https://git.openjdk.java.net/jdk/pull/1771

From smarks at openjdk.java.net  Wed Dec 16 22:17:56 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 16 Dec 2020 22:17:56 GMT
Subject: RFR: 8253497: Core Libs Terminology Refresh [v5]
In-Reply-To: <YtcsLXC3RyluT0sdpQPKNnU3hFe3v8gnEC1hB00hHhI=.949b851d-5e2a-4e61-a83e-f13cb0afa1ec@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
 <YtcsLXC3RyluT0sdpQPKNnU3hFe3v8gnEC1hB00hHhI=.949b851d-5e2a-4e61-a83e-f13cb0afa1ec@github.com>
Message-ID: <7eyzI35LC0CuYkwMo5nfLC8CrEZxmIcX8GfbSKy91MI=.d3322944-9580-410c-b387-490742c36c5a@github.com>

On Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
>> 
>> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
>> 1. grandfathered -> legacy
>> 2. blacklist -> filter or reject
>> 3. whitelist -> allow or accept
>> 4. master -> coordinator
>> 5. slave -> worker
>> 
>> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use quotes instead of @code in Locale

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From bchristi at openjdk.java.net  Wed Dec 16 23:12:55 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 16 Dec 2020 23:12:55 GMT
Subject: Integrated: 8253497: Core Libs Terminology Refresh
In-Reply-To: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
References: <Q9n5PnfVVjVHNYG2TXoENP74QpQXuLfQhY7FuLyX47g=.56731360-cafe-44cb-b119-0d6b681def11@github.com>
Message-ID: <pHBg-ZCup9YJny2THa4bJtMYhdBb5Rj1ln30zVjaA1w=.5d97c032-d5d5-40c3-84f6-5003170d3b35@github.com>

On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> This is part of an effort in the JDK to replace archaic/non-inclusive words with more neutral terms (see JDK-8253315 for details).
> 
> Here are the changes covering core libraries code and tests.  Terms were changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
> 
> Addressing similar issues in upstream 3rd party code is out of scope of this PR.  Such changes will be picked up from their upstream sources.

This pull request has now been integrated.

Changeset: b2f03554
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2f03554
Stats:     82 lines in 15 files changed: 1 ins; 0 del; 81 mod

8253497: Core Libs Terminology Refresh

Reviewed-by: naoto, kcr, rriggs, joehw, bpb, smarks, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/1771

From chegar at openjdk.java.net  Thu Dec 17 09:51:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 17 Dec 2020 09:51:58 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <8e6vsmTl1qRfnmuLSFn30Yy9ck2SJVcBjdR_flRzB60=.65cd22bb-6d0e-400b-a919-d9634c0f988a@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

Looks good to me.

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/20

From alanb at openjdk.java.net  Thu Dec 17 10:33:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Dec 2020 10:33:00 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:

> 100:      */
> 101:     public boolean equals(Object other) {
> 102:         if (this == other) {

It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 11:37:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 11:37:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
Message-ID: <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>

On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   take advantage of "flow scoping" to eliminate casts
>
> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:
> 
>> 100:      */
>> 101:     public boolean equals(Object other) {
>> 102:         if (this == other) {
> 
> It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.

Actually, I'm not sure if `oth` is better name for variable than `other1`.
I would say they have the same rank :)

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

PR: https://git.openjdk.java.net/jdk/pull/20

From aefimov at openjdk.java.net  Thu Dec 17 13:18:59 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Thu, 17 Dec 2020 13:18:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
Message-ID: <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>

On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>   take advantage of "flow scoping" to eliminate casts

Thank you for checking `HttpURLConnection` and `Socket`.
The latest version looks good to me.

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

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/20

From dfuchs at openjdk.java.net  Thu Dec 17 13:34:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 13:34:59 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
 <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
Message-ID: <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>

On Thu, 17 Dec 2020 11:35:26 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/Signal.java line 102:
>> 
>>> 100:      */
>>> 101:     public boolean equals(Object other) {
>>> 102:         if (this == other) {
>> 
>> It might be a bit cleaner to rename Object other to "obj" to avoid having Object other and Signal other1.
>
> Actually, I'm not sure if `oth` is better name for variable than `other1`.
> I would say they have the same rank :)

I believe Alan is suggesting to do:

    /**
     * Compares the equality of two <code>Signal</code> objects.
     *
     * @param obj the object to compare with.
     * @return whether two <code>Signal</code> objects are equal.
     */
    public boolean equals(Object obj) {
        if (this == obj) {

this leaves the variable name `other` free for later use inside the method.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From alanb at openjdk.java.net  Thu Dec 17 13:38:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 17 Dec 2020 13:38:57 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <FJV5RZhAc4IhdF1PRko3TdtKE3OksnHOsESqWv9nMuY=.5c06a817-207e-4c05-bd25-4a6383aebee2@github.com>
 <OhbufpiqLK8_tQILCnL0ZhSYBtEibI_03D9iNx9XO-4=.132bf966-8db1-43d6-ad0d-eb2ba5ba26af@github.com>
 <cFlHBI-U_MBs4lVcpPKTbLMOXv7tN-e8w4kegYu2QKg=.ddbbc288-172c-4905-a6b6-2c4300a73f80@github.com>
Message-ID: <QDrICqJdKtCEC0VU02zOE-eFS7zMuTG8yg-qQU2ZNPc=.467a1222-ec6f-4365-bf84-5576e0801d6d@github.com>

On Thu, 17 Dec 2020 13:32:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Actually, I'm not sure if `oth` is better name for variable than `other1`.
>> I would say they have the same rank :)
>
> I believe Alan is suggesting to do:
> 
>     /**
>      * Compares the equality of two <code>Signal</code> objects.
>      *
>      * @param obj the object to compare with.
>      * @return whether two <code>Signal</code> objects are equal.
>      */
>     public boolean equals(Object obj) {
>         if (this == obj) {
> 
> this leaves the variable name `other` free for later use inside the method.

> Actually, I'm not sure if `oth` is better name for variable than `other1`.
> I would say they have the same rank :)

Sorry, I should have been clearer, the comment was about equals(Object other). If you rename "other" then it will avoid "other1"

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

PR: https://git.openjdk.java.net/jdk/pull/20

From chegar at openjdk.java.net  Thu Dec 17 13:55:19 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 17 Dec 2020 13:55:19 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v5]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <sogVxBTra1OWQhWLzMwWqNnISJ2n-5CRHjTglM3DkdE=.44ba71db-31b0-48ef-ba92-616b9e124cb1@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty 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:

 - Template generation of carrier specific micro-benchmarks.
   
   * Benchmarks are now split out into carrier specific source files
   * All variants and views are covered
   * Test scenario naming is idiomatic
   
   Even with the split by carrier, regex expressions can be used to easily run subsets the benchmarks. E.g. test all memory operations related to Short with read-only buffers:
   
   $ java -jar benchmarks.jar "org.openjdk.bench.java.nio..*Buffers.testDirect.*Short.*"  -l
   Benchmarks:
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortRO
   org.openjdk.bench.java.nio.ByteBuffers.testDirectLoopGetShortSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectBulkGetShortViewSwapRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewRO
   org.openjdk.bench.java.nio.ShortBuffers.testDirectLoopGetShortViewSwapRO
 - Merge branch 'master' into bb-bench
 - Add explicitly allocated heap carrier buffer tests
 - Replace Single with Loop
 - whitespace
 - Add additional carrier views and endianness variants.
   
   A large number of variants are now covered. The individual benchmarks conform to the following convention:
     test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
   
   This allows to easily run a subset of particular interest. For example:
     Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
     Char only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
     Bulk only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
     Put with Int or Long carrier :-
        test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
   
   Running all variants together is likely not all that useful, since there will be a lot of data.
   
   The param sizes are changed so as to better allow for wider carrier views.
   
   There are a lot of individual benchmark methods, but their implementation is trivial, and largely mechanical.
   
   Question: where do folk stand on having a `main` method in a benchmark - as a standalone-run sanity? I found this useful to assert the validity of the benchmark code. It can be commented out if it could somehow affect the benchmark runs.
   
   ( I omitted read-only views, since they less interesting, and we already have a lot of variants )
 - Initial changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/5ee5d8bf..a8e81a84

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=03-04

  Stats: 46605 lines in 988 files changed: 29018 ins; 8180 del; 9407 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 14:01:14 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 14:01:14 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v5]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/f5727ca9..314217ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From dfuchs at openjdk.java.net  Thu Dec 17 14:22:04 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 17 Dec 2020 14:22:04 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v5]
In-Reply-To: <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <FM5DckNl02dor6zw6sOtjxYRaZLJx1St1zGJA1Or1PU=.6b7f1b04-150d-4e94-a464-1d25d9e18d56@github.com>
Message-ID: <2d3umOCXurFwL9NlMzsBZbyN9U2o1p2VUisHHPzfaxU=.71d60783-f578-4111-a250-3b9820fc8d5a@github.com>

On Thu, 17 Dec 2020 14:01:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base

src/java.base/share/classes/jdk/internal/misc/Signal.java line 101:

> 99:      * @return whether two <code>Signal</code> objects are equal.
> 100:      */
> 101:     public boolean equals(Object oth) {

I'd  suggest to replace `oth` with `obj` and fix the `@param` clause in the method javadoc.

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

PR: https://git.openjdk.java.net/jdk/pull/20

From paul.sandoz at oracle.com  Thu Dec 17 17:31:49 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 17 Dec 2020 09:31:49 -0800
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v3]
In-Reply-To: <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <EqS6UCvJisVURDIVUB8vFFBN1OLeDUigX47IANeLXig=.de448b08-6ae8-495b-adf4-fe9276822ed4@github.com>
 <qIVsVUrawvIPGg7VR6Za-CGKKDwjWq6y4QmyOfrFz_I=.9dcc617d-9350-4b97-a38b-f6d567de17e9@github.com>
Message-ID: <BE8BF6F9-DF88-485A-8F02-6BEA93C0D050@oracle.com>



> On Dec 16, 2020, at 1:47 AM, Chris Hegarty <chegar at openjdk.java.net> wrote:
> 
> On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:
> 
>>> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>> 
>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>  use instanceof pattern matching in UnixPath too
> 
> Let's take advantage of "flow scoping" to eliminate some of these casts. A few examples follow.
> 
> src/java.base/share/classes/java/net/InetSocketAddress.java line 414:
> 
>> 412:         if (!(obj instanceof InetSocketAddress))
>> 413:             return false;
>> 414:         return holder.equals(((InetSocketAddress) obj).holder);
> 
> If we restructure this a little we can get:
> 
>    public final boolean equals(Object obj) {
>        if (obj instanceof InetSocketAddress that)
>            return holder.equals(that.holder);
>        return false;
>    }
> 

It?s also possible to use a ternary expression as in:

   return (obj instanceof InetSocketAddress that) ? holder.equals(that.holder) : false;

Not suggesting you have to do that here. More for information purposes for those that might not know.

Paul.

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 17:43:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 17:43:10 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v6]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <PyqNIExdkDwF_ElHCJYwRAvlKyt6TCR5xTfL6oii51Y=.c324d43b-882e-4cb0-8595-6ec948f40d43@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  rename 'other' -> 'oth', 'other1' -> 'other'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/314217ec..fe303a2c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Thu Dec 17 17:47:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 17 Dec 2020 17:47:12 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v7]
In-Reply-To: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
Message-ID: <bCsOnCfmSL_uteM5YbAiDKGxiQKIp9-AGryuANQbo8E=.b1fe9041-ddee-4b32-8e00-0ada4c7b5995@github.com>

> 8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8258422: Cleanup unnecessary null comparison before instanceof check in java.base
  rename 'oth' -> 'obj'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/20/files
  - new: https://git.openjdk.java.net/jdk/pull/20/files/fe303a2c..5949f9a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=20&range=05-06

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk/pull/20

From jai.forums2013 at gmail.com  Fri Dec 18 04:50:32 2020
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 18 Dec 2020 10:20:32 +0530
Subject: Difference in encoding semantics of URI returned by File.toURI and
 Path.toUri representing the same file
Message-ID: <3cd8d31d-1640-a855-4ba2-bf05be8adfe0@gmail.com>

The java.io.File has a toURI() API which returns a (system dependent) 
URI as per its javadoc. The java.io.File also has a toPath() API which 
then exposes a toUri() API from the java.nio.file.Path. The javadoc of 
the File class doesn't specify any semantics about the toUri() returned 
by the java.nio.file.Path.

More specifically, for the same file instance, is the File.toURI() and 
Path.toUri() expected to return a URI which has the same semantics when 
it comes to encoded characters in the URI?

Consider the following trivial code for what I mean:

import java.net.*;
import java.nio.file.*;
import java.io.*;

public class PathTest {

 ??? public static void main(final String[] args) throws Exception {
 ??? ??? final String location = args[0];

 ??? ??? final Path a = Paths.get(location).toAbsolutePath();
 ??? ??? System.out.println("URI from Paths.get().toUri() API " + a + " 
---> " + a.toUri());

 ??? ??? final Path b = new File(location).toPath().toAbsolutePath();
 ??? ??? System.out.println("URI from File.toPath().toUri() API " + b + 
" ---> " + b.toUri());

 ??? ??? final File c = new File(location).getAbsoluteFile();
 ??? ??? System.out.println("URI from File.toURI() API " + c + " ---> " 
+ c.toURI());

 ??? }
}

The above program prints the URI of a file path using 3 different APIs:

1. Paths.get().toUri()
2. File.toPath().toUri()
3. File.toURI()

When I run the program and pass it a directory which contains a 
non-ascii character (which belongs to the "other" category as explained 
in the URI javadoc[1]) then I see that the URI returned by the 
Path.toUri() differs from the URI returned from the File.toURI() when it 
comes to encoding the "other" category character (i.e. the non-ascii 
character). Here's the command I use and here's the output:

mkdir foob?r
java PathTest foob?r

Output:

URI from Paths.get().toUri() API /private/tmp/delme/foob?r ---> 
file:///private/tmp/delme/fooba%CC%83r/
URI from File.toPath().toUri() API /private/tmp/delme/foob?r ---> 
file:///private/tmp/delme/fooba%CC%83r/
URI from File.toURI() API /private/tmp/delme/foob?r ---> 
file:/private/tmp/delme/foob?r/

Notice that the Path.toUri() version encodes the non-ascii characters 
whereas the File.toURI() doesn't. Is this expected? The javadoc doesn't 
have much details around this.

Now, interestingly, the same program if passed a file path which 
contains a "illegal" character (for example space character as defined 
in[1]), then both the Path.toUri() and File.toURI() return a URI which 
has the character encoded. Here's the output when you run:

mkdir "foo bar"
java PathTest "foo bar"

Output:

URI from Paths.get().toUri() API /private/tmp/delme/foo bar ---> 
file:///private/tmp/delme/foo%20bar
URI from File.toPath().toUri() API /private/tmp/delme/foo bar ---> 
file:///private/tmp/delme/foo%20bar
URI from File.toURI() API /private/tmp/delme/foo bar ---> 
file:/private/tmp/delme/foo%20bar

So it's not clear which categories of the characters will be 
(consistently) encoded by the URI returned by the Path and File 
instances, for the same target file.

[1] 
https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/net/URI.html


-Jaikiran


From chegar at openjdk.java.net  Sat Dec 19 10:31:55 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Sat, 19 Dec 2020 10:31:55 GMT
Subject: RFR: 8258422: Cleanup unnecessary null comparison before
 instanceof check in java.base [v4]
In-Reply-To: <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com>
 <ARIc6xVW9sgAF-dtJkqJJEioKYvGW7EIryrAxuuylU4=.55447480-f0cf-45aa-a6e8-f89090496c47@github.com>
 <WfWVy9NtoNsW2S4UA74_eJAZTwspjzmzwO9mlIXCcCQ=.843478a1-bcd2-497a-9cea-2bd37fb833ad@github.com>
Message-ID: <GQZRQa0eTs-vhF2x1W-wqp3uBpxtR-evPQNPs4eiW9c=.8839784d-fccf-4d5d-ad47-af2c11aed30e@github.com>

On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8258422: Cleanup unnecessary null comparison before instanceof check in java.base
>>   take advantage of "flow scoping" to eliminate casts
>
> Thank you for checking `HttpURLConnection` and `Socket`.
> The latest version looks good to me.

This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this.

[1]: https://bugs.openjdk.java.net/browse/JDK-8258657

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

PR: https://git.openjdk.java.net/jdk/pull/20

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:10:02 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:10:02 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
Message-ID: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>

8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Commit messages:
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

Changes: https://git.openjdk.java.net/jdk/pull/1853/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8080272
  Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:46:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:46:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v2]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <hY6bq5j7bf8POwY5aKS87ncspu7iRgBq-8N8PZsW6Os=.e4ecc2ff-a299-4221-92be-6f98756c933e@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in JrtPath. They compiled with java 8 language level

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From alanb at openjdk.java.net  Sun Dec 20 19:45:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:45:54 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.

We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.

One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:09:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:09:12 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v3]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oNRktI1p1Z3VLqIBLK6yPqk-mDMFmh8EzMrRuHmtp8w=.cdd1f3fe-c7ba-4e83-8220-da2e2582004f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in ASM
  use Files.copy in sjavac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01-02

  Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:15:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:15:09 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v4]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <F5_oGJSwGgKTiBxBuzIa3DietHA6DAukNrG1tKXMwzQ=.89920e48-6c93-4ea9-b383-63dc9ba58fa9@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in MLet too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:22:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:22:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v5]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <vAvbxQL52sRM-zF5IuAEfbLXaj-8xfux8XNvlDyQTno=.f1389529-1b8c-4d5a-a335-bea8d182586f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in Win32PrintJob too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03-04

  Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:25:52 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:25:52 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
Message-ID: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>

On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From prr at openjdk.java.net  Sun Dec 20 20:36:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 20:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
Message-ID: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>

On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.
>> 
>> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.
>> 
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
> 
> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

So these changes are all over the place which means no one person knows how to test all of it.
Have you run the sound, swing tests, and the  printing tests on unix and windows ?
For printing for sure you'll need to do some manual testing.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From fw at deneb.enyo.de  Sun Dec 20 21:50:30 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 20 Dec 2020 22:50:30 +0100
Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer
 memory
In-Reply-To: <CANBJVOHxxA9J4sv25z1ufuYqNmFJeTMECHTMsHGEGgOpS6EJvA@mail.gmail.com>
 (Brett Okken's message of "Mon, 14 Dec 2020 20:22:36 -0600")
References: <CANBJVOHxxA9J4sv25z1ufuYqNmFJeTMECHTMsHGEGgOpS6EJvA@mail.gmail.com>
Message-ID: <87pn344061.fsf@mid.deneb.enyo.de>

* Brett Okken:

>  I am not sure if this is the correct mailing list for this question.
> Please let me know if I should post it somewhere else.
>
> The javadoc for SoftReference states:
>
> All soft references to softly-reachable objects are guaranteed to have been
> cleared before the virtual machine throws an OutOfMemoryError.
>
> But that is not quite true when it comes to allocating direct ByteBuffer
> instances. Would it be possible to clear softly-reachable direct ByteBuffer
> instances prior to throwing java.lang.OutOfMemoryError: Direct buffer
> memory? This would make it much simpler (and safer) to implement a cache of
> direct ByteBuffer instances for re-use.

It's not true in other contexts, either:

jshell> var r = new SoftReference<>(new Object() {});
r ==> java.lang.ref.SoftReference at 57fa26b7

jshell> r.get();
$11 ==> $0 at 2f410acf

jshell> new long[Integer.MAX_VALUE];
|  Exception java.lang.OutOfMemoryError: Requested array size exceeds VM limit

jshell> r.get();
$13 ==> $0 at 2f410acf

jshell> IntStream.range(0, 1000000000).boxed().collect(Collectors.toList()).size();
|  Exception java.lang.OutOfMemoryError: Java heap space

jshell> r.get();
$15 ==> $0 at 2f410acf

If taken literally, the specification requires that the
OutOfMemoryError constructor has to clear all SoftReference objects,
but that does not seem to happen.

I think the intent is to encourage implementations not to report
spurious OOMEs if they could be avoid by clearing soft references.

From serb at openjdk.java.net  Sun Dec 20 22:50:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 20 Dec 2020 22:50:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
Message-ID: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race <prr at openjdk.org> wrote:

>>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>> 
>> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.
>
> So these changes are all over the place which means no one person knows how to test all of it.
> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
> For printing for sure you'll need to do some manual testing.

I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:52:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:52:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v6]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <egekHLmTMOf1zvpBGHF6ho4g2MWS1mY0c_g4elVAGUs=.ba8b3b7f-7b6a-4f4a-95f1-bdc73c7b74db@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04-05

  Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:58:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:58:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
Message-ID: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>

On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So these changes are all over the place which means no one person knows how to test all of it.
>> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
>> For printing for sure you'll need to do some manual testing.
>
> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

I've extracted changes in java.desktop into separate PR #1856
Reverted this changes from current PR.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 08:19:08 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 08:19:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05-06

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From alanb at openjdk.java.net  Mon Dec 21 08:36:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Dec 2020 08:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
 <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com>

On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.
>
> I've extracted changes in java.desktop into separate PR #1856
> Reverted this changes from current PR.

Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:16:11 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:16:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in Apache Santuario

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06-07

  Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 09:47:59 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 09:47:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main`

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:

> 2457:                 byte[] bytes = in.readAllBytes();
> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
> 2459:                         new ByteArrayInputStream(bytes));

Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:53:57 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:53:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
Message-ID: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>

On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
> 
>> 2457:                 byte[] bytes = in.readAllBytes();
>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>> 2459:                         new ByteArrayInputStream(bytes));
> 
> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

Looks like it was done intentionally by original author of the code.
Check comment above:

                // Read the full stream before feeding to X509Factory,
                // otherwise, keytool -gencrl | keytool -printcrl
                // might not work properly, since -gencrl is slow
                // and there's no data in the pipe at the beginning.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 10:06:01 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 10:06:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
 <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
Message-ID: <m7_aUO_Qf7tKkUNuihCnh8Lh83xzYp3AOANwFucPBsE=.201f4482-bd10-4936-b58c-9148b3dd18d3@github.com>

On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>> 
>>> 2457:                 byte[] bytes = in.readAllBytes();
>>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>>> 2459:                         new ByteArrayInputStream(bytes));
>> 
>> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?
>
> Looks like it was done intentionally by original author of the code.
> Check comment above:
> 
>                 // Read the full stream before feeding to X509Factory,
>                 // otherwise, keytool -gencrl | keytool -printcrl
>                 // might not work properly, since -gencrl is slow
>                 // and there's no data in the pipe at the beginning.

Let's keep it then

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From brett.okken.os at gmail.com  Mon Dec 21 13:06:15 2020
From: brett.okken.os at gmail.com (Brett Okken)
Date: Mon, 21 Dec 2020 07:06:15 -0600
Subject: SoftReferences and java.lang.OutOfMemoryError: Direct buffer
 memory
In-Reply-To: <87pn344061.fsf@mid.deneb.enyo.de>
References: <CANBJVOHxxA9J4sv25z1ufuYqNmFJeTMECHTMsHGEGgOpS6EJvA@mail.gmail.com>
 <87pn344061.fsf@mid.deneb.enyo.de>
Message-ID: <CANBJVOFAd_euzDLLK21c76kgP_68HF-mXuOj1CSbyNFyU2ZTsQ@mail.gmail.com>

I certainly understand why new long[Integer.MAX_VALUE] would throw an
OutOfMemoryError without clearing soft references. As you pointed out,
clearing soft references has no chance of helping, as the max array size is
reduced by some "header words".

I am a bit surprised by IntStream.range(0,
1000000000).boxed().collect(Collectors.toList()).size(); not clearing soft
references. Indeed, that does not match what I observe in jdk 11. Though it
does seem reasonable that if the jvm is able to determine that the result
would require more memory than the max heap, to just throw the OOME without
clearing soft references.

The case with direct ByteBuffer instances is a bit different. It is
possible that clearing references (especially if it were possible to only
clear references to direct ByteBuffer instances) would allow the OOME to be
avoided.

On Sun, Dec 20, 2020 at 3:50 PM Florian Weimer <fw at deneb.enyo.de> wrote:

> * Brett Okken:
>
> >  I am not sure if this is the correct mailing list for this question.
> > Please let me know if I should post it somewhere else.
> >
> > The javadoc for SoftReference states:
> >
> > All soft references to softly-reachable objects are guaranteed to have
> been
> > cleared before the virtual machine throws an OutOfMemoryError.
> >
> > But that is not quite true when it comes to allocating direct ByteBuffer
> > instances. Would it be possible to clear softly-reachable direct
> ByteBuffer
> > instances prior to throwing java.lang.OutOfMemoryError: Direct buffer
> > memory? This would make it much simpler (and safer) to implement a cache
> of
> > direct ByteBuffer instances for re-use.
>
> It's not true in other contexts, either:
>
> jshell> var r = new SoftReference<>(new Object() {});
> r ==> java.lang.ref.SoftReference at 57fa26b7
>
> jshell> r.get();
> $11 ==> $0 at 2f410acf
>
> jshell> new long[Integer.MAX_VALUE];
> |  Exception java.lang.OutOfMemoryError: Requested array size exceeds VM
> limit
>
> jshell> r.get();
> $13 ==> $0 at 2f410acf
>
> jshell> IntStream.range(0,
> 1000000000).boxed().collect(Collectors.toList()).size();
> |  Exception java.lang.OutOfMemoryError: Java heap space
>
> jshell> r.get();
> $15 ==> $0 at 2f410acf
>
> If taken literally, the specification requires that the
> OutOfMemoryError constructor has to clear all SoftReference objects,
> but that does not seem to happen.
>
> I think the intent is to encourage implementations not to report
> spurious OOMEs if they could be avoid by clearing soft references.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20201221/f3ff1a94/attachment.htm>

From chegar at openjdk.java.net  Tue Dec 29 15:32:06 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 29 Dec 2020 15:32:06 GMT
Subject: RFR: 8258955: XBuffer.slice(int,
 int) fails to adjust index according to primitive size
Message-ID: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>

Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

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

Commit messages:
 - Fix direct buffer slice

Changes: https://git.openjdk.java.net/jdk/pull/1906/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1906&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258955
  Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1906/head:pull/1906

PR: https://git.openjdk.java.net/jdk/pull/1906

From alanb at openjdk.java.net  Wed Dec 30 09:05:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 30 Dec 2020 09:05:56 GMT
Subject: RFR: 8258955: XBuffer.slice(int,
 int) fails to adjust index according to primitive size
In-Reply-To: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>
References: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>
Message-ID: <QPI52JjDHyBzi_fVTIbHIr-m4Vev9nlrgAJ5LulDMbM=.72aafca1-c382-4d4e-9dab-344fd803a873@github.com>

On Tue, 29 Dec 2020 15:27:38 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

Thanks for picking this up  an oversight when it was added in Java 13 and something we missed when reviewing and testing.

As this is a P3 issue then we could potentially fix this in openjdk/jdk16 during RDP1. If not, it might be something to put into 16.0.1 or 16.0.2.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1906

From chegar at openjdk.java.net  Wed Dec 30 16:16:57 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 30 Dec 2020 16:16:57 GMT
Subject: RFR: 8258955: XBuffer.slice(int,
 int) fails to adjust index according to primitive size
In-Reply-To: <QPI52JjDHyBzi_fVTIbHIr-m4Vev9nlrgAJ5LulDMbM=.72aafca1-c382-4d4e-9dab-344fd803a873@github.com>
References: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>
 <QPI52JjDHyBzi_fVTIbHIr-m4Vev9nlrgAJ5LulDMbM=.72aafca1-c382-4d4e-9dab-344fd803a873@github.com>
Message-ID: <NaemvW4nTfGJAW1lObyZflJ8u2PIfxw1Kg-YPsLCZro=.84006e7c-6b24-4072-a13c-9890f6f8a22e@github.com>

On Wed, 30 Dec 2020 09:03:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.
>
> Thanks for picking this up  an oversight when it was added in Java 13 and something we missed when reviewing and testing.
> 
> As this is a P3 issue then we could potentially fix this in openjdk/jdk16 during RDP1. If not, it might be something to put into 16.0.1 or 16.0.2.

Closing this PR. Instead a PR has been raised against the jdk16 fork, see https://github.com/openjdk/jdk16/pull/73.

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

PR: https://git.openjdk.java.net/jdk/pull/1906

From chegar at openjdk.java.net  Wed Dec 30 16:16:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 30 Dec 2020 16:16:58 GMT
Subject: Withdrawn: 8258955: XBuffer.slice(int,
 int) fails to adjust index according to primitive size
In-Reply-To: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>
References: <x4SmKtAsh2GqgIJmk9y1TqkjPzLpgfXr1xUItrsmzsY=.50cd804f-bf4c-46a5-959e-33704c47543b@github.com>
Message-ID: <Qly_UhTp2WLQddY5jIeJW_Y--0bWJsW9H7cu_4nmWEg=.e7a5bb78-698c-42d2-931b-1fb5738f1055@github.com>

On Tue, 29 Dec 2020 15:27:38 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/1906

From chegar at openjdk.java.net  Wed Dec 30 16:18:12 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 30 Dec 2020 16:18:12 GMT
Subject: [jdk16] RFR: 8258955: (bf) slice(int,
 int) on view buffers fails to adjust index according to primitive size
Message-ID: <l98HM1lQ-c3opT4TbOzCGEBVa_q4HYUKpDXYoXl7JNg=.64dd0550-0d28-41df-940d-22faa1bee4c2@github.com>

Scale the slice start index per carrier width, for views of direct byte buffers. This never worked correctly since being added in Java 13.

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

Commit messages:
 - Fix direct buffer slice

Changes: https://git.openjdk.java.net/jdk16/pull/73/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=73&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258955
  Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/73.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/73/head:pull/73

PR: https://git.openjdk.java.net/jdk16/pull/73

From github.com+471021+marschall at openjdk.java.net  Thu Dec 31 10:15:12 2020
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Thu, 31 Dec 2020 10:15:12 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>

On Thu, 31 Dec 2020 10:10:56 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

A couple of implementation notes:

Reader#read(CharBuffer)

on-heap case

I introduced a dedicated path for the on-heap case and directly read into the backing array. This completely avoids the intermediate allocation and copy. Compared to the initial proposal the buffer position is updated. This has to be done because we bypass the buffer and directly read into the array. This also handles the case that #read returns -1.

I am using a c-style array declaration because the rest of the class uses it.

off-heap case

I limit the intermadiate allocation to TRANSFER_BUFFER_SIZE. In order to reduce the total intermediate allocation we now call #read multiple times until the buffer is full or EOF is reached. This changes the behavior slightly as now possibly more data is read. However this should contribute to reduce the overall intermediate allocations.

A lock is acquired to keep the the read atomic. This is consistent with #skip which also holds a lock over multiple #read calls. This is inconsistent with #transferTo which does not acquire a lock over multiple #read calls. 

The implementation took inspiration from java.io.InputStream#readNBytes(int).

InputStreamReader#read(CharBuffer)

Since StreamDecoder is a Reader as well we can simply delegate.

StreamDecoder#read(CharBuffer)

Interestingly this was not implemented even though StreamDecoder internally works on NIO buffers.

on-heap case

We see a performance improvement and the elimination of all intermediate allocation.

StreamDecoder#read(char[], int, int) and InputStreamReader#read(char[], int, int) may get a small improvement as we no longer #slice the buffer.

off-heap case

We see the elimination of all intermediate allocation but a performance penalty because we hit the slow path in #decodeLoop. There is a trade-off here, we could improve the performance to previous levels by introducing intermediate allocation again. I don't know how much the users of off-heap buffers care about introducing intermediate allocation vs maximum throughput.

I was struggling to come up with microbenchmarks because the built in InputStream and Reader implementations are finite but JMH calls the benchmark methods repeatably. I ended up implementing custom infinite InputStream and Reader implementations. The code can be found there:

https://github.com/marschall/reader-benchmarks/tree/master/src/main/java/com/github/marschall/readerbenchmarks

An Excel with charts can be found here:

https://github.com/marschall/reader-benchmarks/raw/master/src/main/resources/4926314.xlsx

I looked for java.io.Reader#read(CharBuffer) users in the JDK and only found java.util.Scanner#readInput(). I wrote a microbenchmark for this but only found minuscule improvements due to regex dominating the runtime.

There seem to be no direct Reader tests in the tier1 suite, the initial code was wrong because I forgot to update the buffer code position but I only found out because some Scanner tests failed.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Thu Dec 31 10:15:12 2020
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Thu, 31 Dec 2020 10:15:12 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
Message-ID: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>

Implement three optimiztations for Reader.read(CharBuffer)

* Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
* Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
* Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
* Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

Commit messages:
 - 4926314: Optimize Reader.read(CharBuffer)

Changes: https://git.openjdk.java.net/jdk/pull/1915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4926314
  Stats: 101 lines in 3 files changed: 68 ins; 8 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915