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: References: Message-ID: On Mon, 30 Nov 2020 21:59:23 GMT, Lance Andersen 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 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: 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: 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: References: Message-ID: On Wed, 9 Dec 2020 16:52:18 GMT, Brian Burkhalter 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> <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com> Message-ID: On Mon, 30 Nov 2020 20:54:09 GMT, Brian Burkhalter 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: References: Message-ID: > 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: References: Message-ID: On Thu, 10 Dec 2020 12:00:49 GMT, Michael McMahon 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: References: Message-ID: <8nttS4b9_lMxJHzIjJCEUI414mbVHcxiZ0dwr36WbQ0=.e1197a66-9ad3-4923-adbe-4d0ceb10cf83@github.com> On Thu, 10 Dec 2020 12:04:58 GMT, Alan Bateman 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: References: Message-ID: > 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: References: Message-ID: On Thu, 10 Dec 2020 12:05:50 GMT, Alan Bateman 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: References: Message-ID: > 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: References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com> <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@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 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: References: Message-ID: On Thu, 10 Dec 2020 13:10:48 GMT, Michael McMahon 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: References: Message-ID: On Thu, 10 Dec 2020 13:10:48 GMT, Michael McMahon 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: References: Message-ID: On Wed, 9 Dec 2020 11:44:31 GMT, Michael McMahon 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 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: References: Message-ID: On Wed, 9 Dec 2020 16:52:18 GMT, Brian Burkhalter 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 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: 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: References: Message-ID: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Hi Philippe, > On Dec 10, 2020, at 12:03 PM, Philippe Marschall 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: 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: <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 wrote: > > Hi Philippe, > >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall 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: <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 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: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> <727E860F-EA30-4D56-A11C-A8AA0554A7DB@oracle.com> Message-ID: Awesome, I'll work on a PR for this then. Cheers Philippe On Thu, Dec 10, 2020 at 10:04 PM Pavel Rappo 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 wrote: > > > > Hi Philippe, > > > >> On Dec 10, 2020, at 12:03 PM, Philippe Marschall 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: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: On Thu, Dec 10, 2020 at 9:25 PM Brian Burkhalter wrote: > > Hi Philippe, > > On Dec 10, 2020, at 12:03 PM, Philippe Marschall 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: References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: Hello, > On Dec 11, 2020, at 8:31 AM, Philippe Marschall 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: 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: // 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: 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: References: Message-ID: <53123F70-6149-4C83-AC75-05C232FF4557@oracle.com> Hello Andres / Christian, > On Dec 11, 2020, at 12:51 PM, Christian Stein 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 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 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: 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: <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 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 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: 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: References: <0B4A1A1A-B3F4-4A4E-B709-A2949D557CE4@oracle.com> Message-ID: On Fri, Dec 11, 2020 at 5:35 PM Brian Burkhalter 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: 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: References: Message-ID: <6mGHyzJFxdntyaLG6CFPBw87a3I7caQuhWGz8hpLneY=.44f01fb2-a150-42e6-a3b0-853d72d24a1b@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian 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: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian 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: References: Message-ID: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian 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: *

> 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: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian 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: *

> 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: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang 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: *

>> 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: References: Message-ID: > 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: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: On Tue, 15 Dec 2020 01:36:27 GMT, Brent Christian wrote: >> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java line 152: >> >>> 150: *

>>> 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: 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: 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: References: Message-ID: <-neClWA41LmYuPXJnPDfdxEplCuopdn8ze3V3GZQ-YU=.d6c7045b-a6c9-49e6-97f9-a0fa84185ffe@github.com> On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian 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: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> Message-ID: <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang 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: <-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 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: On Sat, 5 Sep 2020 18:55:53 GMT, Andrey Turbanov 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Sat, 31 Oct 2020 19:37:10 GMT, Stuart Marks 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Sun, 4 Oct 2020 11:55:50 GMT, Andrey Turbanov 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Mon, 2 Nov 2020 09:15:31 GMT, Chris Hegarty 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 2 Dec 2020 20:15:02 GMT, Andrey Turbanov 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: > 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: References: Message-ID: On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian 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: References: Message-ID: On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter 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: References: Message-ID: On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen 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: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie 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: References: Message-ID: > 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: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian 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: References: Message-ID: On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian 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: References: <8AAYm6R8mELwB5SCh1OMouMRsJxK1HJbY8YF_27Vt0g=.cd499dba-ef15-4283-ad9e-154efc5319d0@github.com> <-lt5TUB2HeKHv4YDbsHzTBucn1FqzcU3dgUIGi3DF6Y=.8cea83a2-6ff4-4692-9be7-cd11fa2879bc@github.com> Message-ID: On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks 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: References: Message-ID: > 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: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian 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: References: Message-ID: On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian 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: *

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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <_LvzyyCLPoXsNJNNlU_qBmje3U5RvwKifXod1bN5Yc8=.b11b4f6e-16e0-4f92-a052-b55dc2fecb33@github.com> On Tue, 15 Dec 2020 19:52:31 GMT, Andrey Turbanov 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: > 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov 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: > 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 09:44:37 GMT, Chris Hegarty 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 18:27:35 GMT, Aleksei Efimov 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: References: Message-ID: <_3eyagnLPeaqOmlVW65dLaW-Wml-BqQHSAtqFGgtzcE=.1168634c-3ed4-457a-867c-5d8bcd0d12c1@github.com> On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman 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: *

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: References: Message-ID: > 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: References: Message-ID: <7eyzI35LC0CuYkwMo5nfLC8CrEZxmIcX8GfbSKy91MI=.d3322944-9580-410c-b387-490742c36c5a@github.com> On Wed, 16 Dec 2020 20:08:11 GMT, Brent Christian 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: References: Message-ID: On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian 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 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <8e6vsmTl1qRfnmuLSFn30Yy9ck2SJVcBjdR_flRzB60=.65cd22bb-6d0e-400b-a919-d9634c0f988a@github.com> On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 10:29:50 GMT, Alan Bateman 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Wed, 16 Dec 2020 10:32:12 GMT, Andrey Turbanov 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 11:35:26 GMT, Andrey Turbanov 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 Signal objects. * * @param obj the object to compare with. * @return whether two Signal 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 13:32:06 GMT, Daniel Fuchs 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 Signal objects. > * > * @param obj the object to compare with. > * @return whether two Signal 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: > 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: > 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: <2d3umOCXurFwL9NlMzsBZbyN9U2o1p2VUisHHPzfaxU=.71d60783-f578-4111-a250-3b9820fc8d5a@github.com> On Thu, 17 Dec 2020 14:01:14 GMT, Andrey Turbanov 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 Signal 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: > On Dec 16, 2020, at 1:47 AM, Chris Hegarty wrote: > > On Wed, 16 Dec 2020 09:20:09 GMT, Andrey Turbanov 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: > 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: > 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: References: <_dsteIZR8JkLGBdQ3H2PH8lhZhp-0Cy-eP-Ornz3TVo=.727df0ae-418b-43ba-a196-9d762c302583@github.com> Message-ID: On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov 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: 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: References: Message-ID: > 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: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: > 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: References: Message-ID: On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman 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: References: Message-ID: On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov 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: (Brett Okken's message of "Mon, 14 Dec 2020 20:22:36 -0600") References: 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: References: Message-ID: On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race 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: References: Message-ID: > 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: References: Message-ID: On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov 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: References: Message-ID: > 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: References: Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com> On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov 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: References: Message-ID: > 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: References: Message-ID: On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov 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: References: Message-ID: On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? 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: References: Message-ID: On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov 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: <87pn344061.fsf@mid.deneb.enyo.de> Message-ID: 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 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: 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: 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: References: Message-ID: On Tue, 29 Dec 2020 15:27:38 GMT, Chris Hegarty 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: References: Message-ID: On Wed, 30 Dec 2020 09:03:33 GMT, Alan Bateman 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: References: Message-ID: On Tue, 29 Dec 2020 15:27:38 GMT, Chris Hegarty 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: 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: References: 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 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: 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