From jjg at openjdk.org Thu Dec 1 19:36:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:36:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons 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 five additional commits since the last revision: - Change ietf.org URLs to use rfc-editor.org - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags - Remove updates from unexported files - Prefix RFC titles with `RFC NNNN:` - JDK-8296547: Add @spec tags to API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02-03 Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:40:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:40:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato wrote: >> Jonathan Gibbons 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 five additional commits since the last revision: >> >> - Change ietf.org URLs to use rfc-editor.org >> - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags >> - Remove updates from unexported files >> - Prefix RFC titles with `RFC NNNN:` >> - JDK-8296547: Add @spec tags to API > > src/java.base/share/classes/java/lang/Character.java line 172: > >> 170: * occur. For example, in a future release, synchronization may fail. >> 171: * >> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 > > This should probably be removed, as the original link (explaining `U+n` notation) is broken. @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:57:33 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:57:33 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove updates from unexported files > > src/java.xml/share/classes/javax/xml/XMLConstants.java line 35: > >> 33: * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition) >> 34: * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition) >> 35: * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition > > Hi Jon, > > I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0. > points to the fifth edition while @see second. > > A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read. > > [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work. The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From naoto at openjdk.org Thu Dec 1 21:23:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Dec 2022 21:23:09 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons wrote: >> src/java.base/share/classes/java/lang/Character.java line 172: >> >>> 170: * occur. For example, in a future release, synchronization may fail. >>> 171: * >>> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 >> >> This should probably be removed, as the original link (explaining `U+n` notation) is broken. > > @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. Either way is fine with me. I will fix it up if you choose the latter. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From dfuchs at openjdk.org Fri Dec 2 12:15:23 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Dec 2022 12:15:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com> On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons 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 five additional commits since the last revision: > > - Change ietf.org URLs to use rfc-editor.org > - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags > - Remove updates from unexported files > - Prefix RFC titles with `RFC NNNN:` > - JDK-8296547: Add @spec tags to API I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now. src/java.base/share/classes/java/net/StandardSocketOptions.java line 62: > 60: * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams > 61: * @see RFC 929: > 62: * Broadcasting Internet Datagrams This `@see` line should now be removed since it's referencing the exact same document. src/java.base/share/classes/java/net/StandardSocketOptions.java line 83: > 81: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 82: * @see RFC 1122 > 83: * Requirements for Internet Hosts -- Communication Layers Same remark here: please remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 154: > 152: * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance > 153: * @see RFC 1323: TCP > 154: * Extensions for High Performance Remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 186: > 184: * > 185: * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol > 186: * @see RFC 793: Transmission Remove the @see src/java.base/share/classes/java/net/StandardSocketOptions.java line 377: > 375: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 376: * @see RFC 1122: > 377: * Requirements for Internet Hosts -- Communication Layers Remove the @see src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122: > 120: * @see 121: * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609, > 122: * "Service Templates and Service: Schemes" The two `@see` should now be removed ------------- Changes requested by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11073 From jpai at openjdk.org Mon Dec 5 09:28:02 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Dec 2022 09:28:02 GMT Subject: RFR: 8297682: Use Collections.emptyIterator where applicable In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov wrote: > Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method. > Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method. UnixFileSystem change looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11025 From mcimadamore at openjdk.org Mon Dec 5 10:31:52 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 10:31:52 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: References: Message-ID: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix Preview annotation for JEP 434 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/8b5dc0f0..33b834ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37-38 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From sundar at openjdk.org Mon Dec 5 11:03:15 2022 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Mon, 5 Dec 2022 11:03:15 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Preview annotation for JEP 434 LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Dec 5 13:49:46 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 13:49:46 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Preview annotation for JEP 434 Note: there are 4 tests failing in x86: * MemoryLayoutPrincipalTotalityTest * MemoryLayoutTypeRetentionTest * TestLargeSegmentCopy * TestLinker These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Dec 5 13:55:22 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 13:55:22 GMT Subject: Integrated: 8295044: Implementation of Foreign Function and Memory API (Second Preview) In-Reply-To: References: Message-ID: <7Ara-NxY9rdQzABZPYR9T-N7b1XLY99_6J-dG3cr2NY=.4151c690-0138-4ffd-a763-ff2456754189@github.com> On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 This pull request has now been integrated. Changeset: 73baadce Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/73baadceb60029f6340c1327118aeb59971c2434 Stats: 13808 lines in 255 files changed: 5780 ins; 4448 del; 3580 mod 8295044: Implementation of Foreign Function and Memory API (Second Preview) Co-authored-by: Jorn Vernee Co-authored-by: Per Minborg Co-authored-by: Maurizio Cimadamore Reviewed-by: jvernee, pminborg, psandoz, alanb, sundar ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Mon Dec 5 17:00:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Dec 2022 17:00:50 GMT Subject: RFR: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY Message-ID: PollingWatchService is an implementation of WatchService for platforms that don't have a native implementation. It works by polling the timestamps of files in the registered directories. When a WatchService is initially created, the first poll should be at the polling interval. The changes in JDK-8285956 were intended to reduce the polling interval to 2s but also changed the initial poll to 1s. This PR just restores that part of the change so the first poll after creation will be at the polling interval, which was how it was originally before that change. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/11499/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11499&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298057 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11499.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11499/head:pull/11499 PR: https://git.openjdk.org/jdk/pull/11499 From bpb at openjdk.org Mon Dec 5 17:51:16 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Dec 2022 17:51:16 GMT Subject: RFR: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY In-Reply-To: References: Message-ID: On Sun, 4 Dec 2022 11:08:21 GMT, Alan Bateman wrote: > PollingWatchService is an implementation of WatchService for platforms that don't have a native implementation. It works by polling the timestamps of files in the registered directories. When a WatchService is initially created, the first poll should be at the polling interval. The changes in JDK-8285956 were intended to reduce the polling interval to 2s but also changed the initial poll to 1s. This PR just restores that part of the change so the first poll after creation will be at the polling interval, which was how it was originally before that change. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11499 From jpai at openjdk.org Tue Dec 6 02:05:12 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Dec 2022 02:05:12 GMT Subject: RFR: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY In-Reply-To: References: Message-ID: On Sun, 4 Dec 2022 11:08:21 GMT, Alan Bateman wrote: > PollingWatchService is an implementation of WatchService for platforms that don't have a native implementation. It works by polling the timestamps of files in the registered directories. When a WatchService is initially created, the first poll should be at the polling interval. The changes in JDK-8285956 were intended to reduce the polling interval to 2s but also changed the initial poll to 1s. This PR just restores that part of the change so the first poll after creation will be at the polling interval, which was how it was originally before that change. Looks fine to me. The copyright year will need an update. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11499 From alanb at openjdk.org Tue Dec 6 07:17:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Dec 2022 07:17:04 GMT Subject: RFR: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 02:01:09 GMT, Jaikiran Pai wrote: > The copyright year will need an update. Thanks, I had missed that this needs to be update. Will do that before integrating. ------------- PR: https://git.openjdk.org/jdk/pull/11499 From alanb at openjdk.org Tue Dec 6 07:20:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Dec 2022 07:20:30 GMT Subject: RFR: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY [v2] In-Reply-To: References: Message-ID: > PollingWatchService is an implementation of WatchService for platforms that don't have a native implementation. It works by polling the timestamps of files in the registered directories. When a WatchService is initially created, the first poll should be at the polling interval. The changes in JDK-8285956 were intended to reduce the polling interval to 2s but also changed the initial poll to 1s. This PR just restores that part of the change so the first poll after creation will be at the polling interval, which was how it was originally before that change. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update copyright header - Merge - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11499/files - new: https://git.openjdk.org/jdk/pull/11499/files/f3db40de..446127da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11499&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11499&range=00-01 Stats: 21393 lines in 532 files changed: 10397 ins; 6494 del; 4502 mod Patch: https://git.openjdk.org/jdk/pull/11499.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11499/head:pull/11499 PR: https://git.openjdk.org/jdk/pull/11499 From alanb at openjdk.org Tue Dec 6 07:34:57 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Dec 2022 07:34:57 GMT Subject: Integrated: 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY In-Reply-To: References: Message-ID: On Sun, 4 Dec 2022 11:08:21 GMT, Alan Bateman wrote: > PollingWatchService is an implementation of WatchService for platforms that don't have a native implementation. It works by polling the timestamps of files in the registered directories. When a WatchService is initially created, the first poll should be at the polling interval. The changes in JDK-8285956 were intended to reduce the polling interval to 2s but also changed the initial poll to 1s. This PR just restores that part of the change so the first poll after creation will be at the polling interval, which was how it was originally before that change. This pull request has now been integrated. Changeset: 923c7466 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/923c746650204e36053251c19cf91b7e41e938b0 Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod 8298057: (fs) Remove PollingWatchService.POLLING_INIT_DELAY Reviewed-by: bpb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11499 From pminborg at openjdk.org Tue Dec 6 10:06:28 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 Dec 2022 10:06:28 GMT Subject: RFR: 8296024: Usage of DirectBuffer::address should be guarded [v18] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge master - Remove session exposure - Re-introduce yet another address vairable - Re-introduce address variables - Reformat and fix comment - Remove redundant method - Cleanup - Refactor to try-finally handling - Remove redundant guard and fix comment permanently - Rework Acquisition - ... and 9 more: https://git.openjdk.org/jdk/compare/a6139985...cd95bc86 ------------- Changes: https://git.openjdk.org/jdk/pull/11260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=17 Stats: 809 lines in 24 files changed: 377 ins; 172 del; 260 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Tue Dec 6 10:47:59 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 6 Dec 2022 10:47:59 GMT Subject: Integrated: 8296024: Usage of DirectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. This pull request has now been integrated. Changeset: 84b927a0 Author: Per Minborg Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/84b927a05bcb7bf32a12829070ffd3a5670066d2 Stats: 809 lines in 24 files changed: 377 ins; 172 del; 260 mod 8296024: Usage of DirectBuffer::address should be guarded Reviewed-by: mcimadamore, alanb, psandoz, bpb ------------- PR: https://git.openjdk.org/jdk/pull/11260 From bpb at openjdk.org Tue Dec 6 18:49:26 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 18:49:26 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value Message-ID: Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. ------------- Commit messages: - 8297814: (fs) Re-visit Path.getExtension return value Changes: https://git.openjdk.org/jdk/pull/11545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11545&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297814 Stats: 70 lines in 2 files changed: 10 ins; 8 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/11545.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11545/head:pull/11545 PR: https://git.openjdk.org/jdk/pull/11545 From bpb at openjdk.org Tue Dec 6 18:49:27 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 18:49:27 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:15:15 GMT, Brian Burkhalter wrote: > Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. This proposal would modify the value of the returned extension as shown in this table: | Path | #8066 | This PR | | --------------- | ------------------| --------------------- | | ?a/b/c/foo.jpg? | "jpg" | ".jpg" | | ?a/b/c/foo.? | "" (empty string) | "." (a single period) | | ?a/b/c/foo? | `null` | "" (empty string) | Note that the definition of the file name extension is changed to include the extension separator period character ('.', U+002E FULL STOP). For example, for the audio file `Crescent.flac`, the returned string will be `.flac` instead of `flac`. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From dfuchs at openjdk.org Tue Dec 6 19:08:20 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Dec 2022 19:08:20 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:15:15 GMT, Brian Burkhalter wrote: > Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. src/java.base/share/classes/java/nio/file/Path.java line 278: > 276: * return ""; > 277: * else if (lastPeriod == fileName.length() - 1) > 278: * return "."; I believe you could remove these two lines (277-278) - as the case where the last period is the last character in the string should now fold into the case where it is followed by some (non-period) characters. src/java.base/share/classes/java/nio/file/Path.java line 305: > 303: // the extension is "." if the last dot is the last character > 304: if (lastDot == fileNameString.length() - 1) // lastDot > 0 > 305: return "."; Although this is not needed it's probably a good optimization. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From bpb at openjdk.org Tue Dec 6 19:08:22 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 19:08:22 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 19:02:07 GMT, Daniel Fuchs wrote: >> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. > > src/java.base/share/classes/java/nio/file/Path.java line 278: > >> 276: * return ""; >> 277: * else if (lastPeriod == fileName.length() - 1) >> 278: * return "."; > > I believe you could remove these two lines (277-278) - as the case where the last period is the last character in the string should now fold into the case where it is followed by some (non-period) characters. Yes, I was aware of that but decided to leave it in and get comments. > src/java.base/share/classes/java/nio/file/Path.java line 305: > >> 303: // the extension is "." if the last dot is the last character >> 304: if (lastDot == fileNameString.length() - 1) // lastDot > 0 >> 305: return "."; > > Although this is not needed it's probably a good optimization. That was my thought. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From dfuchs at openjdk.org Tue Dec 6 19:19:00 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 6 Dec 2022 19:19:00 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 18:15:15 GMT, Brian Burkhalter wrote: > Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. test/jdk/java/nio/file/Path/Extensions.java line 76: > 74: {"compress.gzip", ".gzip"}, > 75: {"waitwhat.&$!#%", ".&$!#%"}, > 76: {"6.283185307", ".283185307"} For completeness you might also want to include: a..b a..b.c a.b..c a..b. .a..b .a..b.c .a.b..c .a..b. ..a..b ..a..b.c ..a.b..c ..a..b. These tests are cheap :-) ------------- PR: https://git.openjdk.org/jdk/pull/11545 From smarks at openjdk.org Tue Dec 6 20:05:54 2022 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 6 Dec 2022 20:05:54 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value In-Reply-To: References: Message-ID: <-QJQYFEFyfAry725McecbwMwR707SLHHhlp3BS9hY0s=.d0144ab4-4d7f-4cd9-b41a-d88092f94f46@github.com> On Tue, 6 Dec 2022 19:03:38 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/nio/file/Path.java line 278: >> >>> 276: * return ""; >>> 277: * else if (lastPeriod == fileName.length() - 1) >>> 278: * return "."; >> >> I believe you could remove these two lines (277-278) - as the case where the last period is the last character in the string should now fold into the case where it is followed by some (non-period) characters. > > Yes, I was aware of that but decided to leave it in and get comments. Since this is part of the specification, the simpler it is, the better. >> src/java.base/share/classes/java/nio/file/Path.java line 305: >> >>> 303: // the extension is "." if the last dot is the last character >>> 304: if (lastDot == fileNameString.length() - 1) // lastDot > 0 >>> 305: return "."; >> >> Although this is not needed it's probably a good optimization. > > That was my thought. I'm not sure this is a useful optimization. It does a bit more computation in order to save a string allocation. It probably doesn't occur very frequently though so I don't think this saves much. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From bpb at openjdk.org Tue Dec 6 22:15:23 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 22:15:23 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: > Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8297814: Address reviewer comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11545/files - new: https://git.openjdk.org/jdk/pull/11545/files/1c240293..af098065 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11545&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11545&range=00-01 Stats: 29 lines in 2 files changed: 13 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11545.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11545/head:pull/11545 PR: https://git.openjdk.org/jdk/pull/11545 From bpb at openjdk.org Tue Dec 6 22:15:25 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 22:15:25 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: <-QJQYFEFyfAry725McecbwMwR707SLHHhlp3BS9hY0s=.d0144ab4-4d7f-4cd9-b41a-d88092f94f46@github.com> References: <-QJQYFEFyfAry725McecbwMwR707SLHHhlp3BS9hY0s=.d0144ab4-4d7f-4cd9-b41a-d88092f94f46@github.com> Message-ID: On Tue, 6 Dec 2022 20:01:45 GMT, Stuart Marks wrote: >> Yes, I was aware of that but decided to leave it in and get comments. > > Since this is part of the specification, the simpler it is, the better. Simplified in af0980652e88297166251d44dd7d0ae79b8e6633. >> That was my thought. > > I'm not sure this is a useful optimization. It does a bit more computation in order to save a string allocation. It probably doesn't occur very frequently though so I don't think this saves much. Removed in af0980652e88297166251d44dd7d0ae79b8e6633. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From bpb at openjdk.org Tue Dec 6 22:15:27 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Dec 2022 22:15:27 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 19:12:23 GMT, Daniel Fuchs wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8297814: Address reviewer comments > > test/jdk/java/nio/file/Path/Extensions.java line 76: > >> 74: {"compress.gzip", ".gzip"}, >> 75: {"waitwhat.&$!#%", ".&$!#%"}, >> 76: {"6.283185307", ".283185307"} > > For completeness you might also want to include: > > a..b > a..b.c > a.b..c > a..b. > .a..b > .a..b.c > .a.b..c > .a..b. > ..a..b > ..a..b.c > ..a.b..c > ..a..b. > > These tests are cheap :-) Added in af0980652e88297166251d44dd7d0ae79b8e6633. ------------- PR: https://git.openjdk.org/jdk/pull/11545 From smarks at openjdk.org Wed Dec 7 00:42:06 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 7 Dec 2022 00:42:06 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: <61e-jGJYl_MN01vnH5NqaBPCJQcqVBL9ZPk23y89YFQ=.8679e249-64a7-413c-9c1c-07afab5f719c@github.com> On Tue, 6 Dec 2022 22:15:23 GMT, Brian Burkhalter wrote: >> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297814: Address reviewer comments Updates look good. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.org/jdk/pull/11545 From jpai at openjdk.org Wed Dec 7 06:15:53 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Dec 2022 06:15:53 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 22:15:23 GMT, Brian Burkhalter wrote: >> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297814: Address reviewer comments Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11545 From dfuchs at openjdk.org Wed Dec 7 11:40:07 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 7 Dec 2022 11:40:07 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 22:15:23 GMT, Brian Burkhalter wrote: >> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297814: Address reviewer comments LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11545 From lancea at openjdk.org Wed Dec 7 12:06:42 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 7 Dec 2022 12:06:42 GMT Subject: RFR: 8297814: (fs) Re-visit Path.getExtension return value [v2] In-Reply-To: References: Message-ID: On Tue, 6 Dec 2022 22:15:23 GMT, Brian Burkhalter wrote: >> Revise `java.nio.file.Path::getExtension` never to return `null` and to simplify implementing other path manipulations such as removing and replacing the file name extension. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297814: Address reviewer comments Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11545 From mik3hall at gmail.com Wed Dec 7 13:55:32 2022 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 7 Dec 2022 07:55:32 -0600 Subject: RFR: 8293067: (fs) Implement WatchService using system library (macOS) In-Reply-To: <0D77CBEB-FEC0-4555-A970-77B829E7F779@gmail.com> References: <-HM3C22k7j9w8aIQ2DlFqmvIFvfIAStZvxrgEzzJGaA=.9f558890-86f5-426c-b341-6cb824a17368@github.com> <9CB76C25-7A7E-4DE5-9E9B-ED28F244AFD2@gmail.com> <0D77CBEB-FEC0-4555-A970-77B829E7F779@gmail.com> Message-ID: <10589B18-6D55-4AC3-B2EA-A6F608334895@gmail.com> > On Nov 30, 2022, at 11:09 AM, Michael Hall wrote: > > > >> On Nov 30, 2022, at 7:59 AM, Maxim Kartashev > wrote: >> >> FWIW I'm on 10.15 >> >> On Wed, Nov 30, 2022 at 4:31 PM Michael Hall > wrote: >> >> >>> On Nov 13, 2022, at 9:31 AM, Alan Bateman > wrote: >>> >>> Unfortunately there is a lot of timeouts and intermittent failures and across quite a range of macOS releases (from 10.15 to 12.2). >> >> Are there any errors after 12.2. I am 12.6. I am not sure what Maxim is. Is it possible it was an Apple issue that is fixed in recent releases? >> > > I guess we?re lucky or there?s something different about the failing infrastructure. Another, maybe remote, possibility - if it?s not the testing framework, or a fixed Apple bug, possibly it?s some quirk in different Xcode versions being used to build the jdk? https://git.openjdk.org/jdk/pull/11115 Appears to correct the Xcode build issues I ran into earlier for Xcode 14. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Wed Dec 7 17:23:52 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Dec 2022 17:23:52 GMT Subject: RFR: 8298303: (fs) temporarily remove Path.getExtension Message-ID: Remove `java.nio.file.Path::getExtension` from the JDK 20 mainline to allow its definition time to settle. ------------- Commit messages: - 8298303: (fs) temporarily remove Path.getExtension Changes: https://git.openjdk.org/jdk/pull/11566/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11566&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298303 Stats: 143 lines in 2 files changed: 0 ins; 142 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11566.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11566/head:pull/11566 PR: https://git.openjdk.org/jdk/pull/11566 From smarks at openjdk.org Wed Dec 7 17:23:53 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 7 Dec 2022 17:23:53 GMT Subject: RFR: 8298303: (fs) temporarily remove Path.getExtension In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 17:01:59 GMT, Brian Burkhalter wrote: > Remove `java.nio.file.Path::getExtension` from the JDK 20 mainline to allow its definition time to settle. Looks like a straightforward backout of relevant code and doc comments from JDK-8057113. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.org/jdk/pull/11566 From alanb at openjdk.org Wed Dec 7 17:23:53 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Dec 2022 17:23:53 GMT Subject: RFR: 8298303: (fs) temporarily remove Path.getExtension In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 17:01:59 GMT, Brian Burkhalter wrote: > Remove `java.nio.file.Path::getExtension` from the JDK 20 mainline to allow its definition time to settle. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11566 From bpb at openjdk.org Wed Dec 7 18:57:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 7 Dec 2022 18:57:12 GMT Subject: Integrated: 8298303: (fs) temporarily remove Path.getExtension In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 17:01:59 GMT, Brian Burkhalter wrote: > Remove `java.nio.file.Path::getExtension` from the JDK 20 mainline to allow its definition time to settle. This pull request has now been integrated. Changeset: 10356e76 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/10356e767a44632c5de142d4666bd85d4618bf71 Stats: 143 lines in 2 files changed: 0 ins; 142 del; 1 mod 8298303: (fs) temporarily remove Path.getExtension Reviewed-by: smarks, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11566 From pminborg at openjdk.org Wed Dec 7 22:04:11 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Dec 2022 22:04:11 GMT Subject: RFR: 8298277: Replace "session" with "scope" for FFM access Message-ID: This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 The PRs contains changes for several sub-components. ------------- Commit messages: - Rename session to scope Changes: https://git.openjdk.org/jdk/pull/11573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298277 Stats: 2783 lines in 98 files changed: 954 ins; 955 del; 874 mod Patch: https://git.openjdk.org/jdk/pull/11573.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573 PR: https://git.openjdk.org/jdk/pull/11573 From jvernee at openjdk.org Wed Dec 7 23:00:08 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 7 Dec 2022 23:00:08 GMT Subject: RFR: 8298277: Replace "session" with "scope" for FFM access In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg wrote: > This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 > > The PRs contains changes for several sub-components. src/java.base/share/classes/jdk/internal/foreign/MemoryScopeImpl.java line 53: > 51: * access is possible when a scope is being closed (see {@link jdk.internal.misc.ScopedMemoryAccess}). > 52: */ > 53: public abstract sealed class MemoryScopeImpl Since the interface is called `SegmentScope`, I think `SegmentScopeImpl` would be a better name here. ------------- PR: https://git.openjdk.org/jdk/pull/11573 From mcimadamore at openjdk.org Wed Dec 7 23:37:03 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Dec 2022 23:37:03 GMT Subject: RFR: 8298277: Replace "session" with "scope" for FFM access In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg wrote: > This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 > > The PRs contains changes for several sub-components. I think we should split this PR into multiple parts: * there are some good javadoc changes in here to the Vector API docs * there are some test changes, where some of the names are out of date * the majority of changes, which is caused by MemorySessionImpl -> MemoryScopeImpl is the part I'm less sure about. I think leaving that as is might be fine for now. ------------- PR: https://git.openjdk.org/jdk/pull/11573 From pminborg at openjdk.org Thu Dec 8 08:17:44 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Dec 2022 08:17:44 GMT Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2] In-Reply-To: References: Message-ID: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com> > This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 > > The PRs contains changes for several sub-components. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Revert renaming of MemorySessionImpl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11573/files - new: https://git.openjdk.org/jdk/pull/11573/files/71a5e29c..39f09aa0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11573&range=00-01 Stats: 172 lines in 25 files changed: 0 ins; 0 del; 172 mod Patch: https://git.openjdk.org/jdk/pull/11573.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11573/head:pull/11573 PR: https://git.openjdk.org/jdk/pull/11573 From stsypanov at openjdk.org Thu Dec 8 12:45:29 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 8 Dec 2022 12:45:29 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base Message-ID: Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like void iterate(T[] items) { if (items.length == 0) { return; } for (T item : items) { //... } } Here if (items.length == 0) { return; } is redundant and can be removed as length check is performed by for-each loop. ------------- Commit messages: - 8298380: Clean up redundant array length checks in JDK code base Changes: https://git.openjdk.org/jdk/pull/11589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298380 Stats: 51 lines in 8 files changed: 0 ins; 14 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/11589.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11589/head:pull/11589 PR: https://git.openjdk.org/jdk/pull/11589 From pminborg at openjdk.org Thu Dec 8 13:05:00 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Dec 2022 13:05:00 GMT Subject: RFR: 8298277: Replace "session" with "scope" for FFM access [v2] In-Reply-To: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com> References: <4y6q6GtQvTrNyp-oA_DtSESbC_jNHX5v1VxOaJRaiVQ=.1b5357b1-9bd3-43e3-8d53-7f4c5714e523@github.com> Message-ID: On Thu, 8 Dec 2022 08:17:44 GMT, Per Minborg wrote: >> This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 >> >> The PRs contains changes for several sub-components. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Revert renaming of MemorySessionImpl I am going to close this PR in favor of several other smaller ones. ------------- PR: https://git.openjdk.org/jdk/pull/11573 From pminborg at openjdk.org Thu Dec 8 13:05:03 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Dec 2022 13:05:03 GMT Subject: Withdrawn: 8298277: Replace "session" with "scope" for FFM access In-Reply-To: References: Message-ID: <0LEwHE6mc-JRS1H07g0SE-jUVPFapFVFxJrreAT8EJI=.a3ed1f57-6126-4324-97c8-86d69f2b67d6@github.com> On Wed, 7 Dec 2022 21:55:43 GMT, Per Minborg wrote: > This PR suggests renaming various names from "session" to "scope" in accordance with https://openjdk.org/jeps/434 > > The PRs contains changes for several sub-components. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11573 From bpb at openjdk.org Thu Dec 8 19:22:52 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 Dec 2022 19:22:52 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ Message-ID: If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. ------------- Commit messages: - 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ Changes: https://git.openjdk.org/jdk/pull/11600/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298187 Stats: 32 lines in 1 file changed: 25 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Thu Dec 8 19:22:52 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 Dec 2022 19:22:52 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:13:03 GMT, Brian Burkhalter wrote: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. The macOS system call `setattrlist(2)` fails to set the last access time supplied as a parameter when the file in question is on an HFS store. It appears to override the parameter value with the current system time at the moment the system call is invoked. The portion of the proposed change starting at line 42 handles the common case where the creation time is _not_ being set. The other more substantial changes further down handle the likely uncommon case where the creation time _is_ being set. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From alanb at openjdk.org Thu Dec 8 19:40:07 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Dec 2022 19:40:07 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:13:03 GMT, Brian Burkhalter wrote: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. I don't think we should put in this workaround as it requires getting the FileStore each time that the last access time is set. This seems like a macOS bug that should be reported to Apple first. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Thu Dec 8 19:45:17 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 Dec 2022 19:45:17 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:37:36 GMT, Alan Bateman wrote: > I don't think we should put in this workaround as it requires getting the FileStore each time that the last access time is set. This seems like a macOS bug that should be reported to Apple first. I agree about reporting it to Apple, but I commented above because the changes starting at line 42 probably would work around most cases. The second group of changes could be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From dholmes at openjdk.org Fri Dec 9 00:14:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 Dec 2022 00:14:49 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. These all seem fine to me. You can count this as the review for hotspot and serviceability. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11589 From amenkov at openjdk.org Fri Dec 9 00:14:50 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Dec 2022 00:14:50 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11589 From serb at openjdk.org Fri Dec 9 00:46:18 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 9 Dec 2022 00:46:18 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. The "client" changes in src/java.desktop looks fine ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11589 From vtewari at openjdk.org Fri Dec 9 06:24:54 2022 From: vtewari at openjdk.org (Vyom Tewari) Date: Fri, 9 Dec 2022 06:24:54 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. java.base changes looks ok to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.org/jdk/pull/11589 From stsypanov at openjdk.org Fri Dec 9 12:54:50 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Fri, 9 Dec 2022 12:54:50 GMT Subject: Integrated: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. This pull request has now been integrated. Changeset: e3c6cf8e Author: Sergey Tsypanov Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/e3c6cf8eaf931d9eb46b429a5ba8d3bbded3728a Stats: 51 lines in 8 files changed: 0 ins; 14 del; 37 mod 8298380: Clean up redundant array length checks in JDK code base Reviewed-by: dholmes, amenkov, serb, vtewari ------------- PR: https://git.openjdk.org/jdk/pull/11589 From alanb at openjdk.org Fri Dec 9 13:25:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Dec 2022 13:25:58 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:42:56 GMT, Brian Burkhalter wrote: > I agree about reporting it to Apple, but I commented above because the changes starting at line 42 probably would work around most cases and do not need the `FileStore`. The second group of changes could be removed. APFS became the default file system in macOS 10.13 so I don't know how common it is to see HFS+ these days. Although we expect it should be rare to be changing the last access time, my concern is that finding the mount point to get the file system type can be problematic in some configurations. It would be good if we could avoid the workaround so I'm interested to see if Apple will fix the bug or not. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From rriggs at openjdk.org Fri Dec 9 14:38:03 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Dec 2022 14:38:03 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer. ------------- PR: https://git.openjdk.org/jdk/pull/11589 From stsypanov at openjdk.org Fri Dec 9 14:48:02 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Fri, 9 Dec 2022 14:48:02 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 14:35:47 GMT, Roger Riggs wrote: >> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like >> >> void iterate(T[] items) { >> if (items.length == 0) { >> return; >> } >> for (T item : items) { >> //... >> } >> } >> >> Here >> >> if (items.length == 0) { >> return; >> } >> >> is redundant and can be removed as length check is performed by for-each loop. > > @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer. @RogerRiggs changes are trivial. Should I revert any of them? ------------- PR: https://git.openjdk.org/jdk/pull/11589 From rriggs at openjdk.org Fri Dec 9 15:54:00 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Dec 2022 15:54:00 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. No, just a reminder to be through in the process. ------------- PR: https://git.openjdk.org/jdk/pull/11589 From bpb at openjdk.org Fri Dec 9 17:58:17 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 Dec 2022 17:58:17 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v2] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Revised not to use FileStore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/a69310a1..a4ac9e75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=00-01 Stats: 49 lines in 1 file changed: 1 ins; 30 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Fri Dec 9 20:39:20 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 Dec 2022 20:39:20 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Message-ID: Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. ------------- Commit messages: - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Changes: https://git.openjdk.org/jdk/pull/11616/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11616&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7093322 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11616.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11616/head:pull/11616 PR: https://git.openjdk.org/jdk/pull/11616 From alanb at openjdk.org Sat Dec 10 08:58:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Dec 2022 08:58:58 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 20:28:31 GMT, Brian Burkhalter wrote: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. src/java.base/share/classes/java/nio/file/Files.java line 2946: > 2944: * {@linkplain BufferedWriter#close close()} or > 2945: * {@linkplain BufferedWriter#flush flush()} > 2946: * was invoked explicitly on the returned {@code BufferedWriter}. There isn't an "underlying stream" here but "file" could work. Alternatively, maybe this would work: "Due to buffering, an IOException due to an encoding error (unmappable-character or malformed-input) may be thrown when writing, flushing or closing the buffered writer." ------------- PR: https://git.openjdk.org/jdk/pull/11616 From alanb at openjdk.org Sat Dec 10 09:19:52 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Dec 2022 09:19:52 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v2] In-Reply-To: References: Message-ID: <7oNFCCc7sDXIcEIrPNQi4MdFqvWCpTao77N4nKrMFuw=.7da409ff-e1cd-439b-926e-fee29c0b707d@github.com> On Fri, 9 Dec 2022 17:58:17 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Revised not to use FileStore Removing the search of the mount points is good but we still have the issue that calling setTimes with a file creation time + another will be two syscalls. The spec for setTimes sets the expectation that the method is not atomic when setting some but not all timestamps, this is because it has to allow for implementation that needs to read the existing timestamps in order to update. The implementation change proposed here may require relaxing the spec Could you look into using file.openForAttributeAccess(followLinks) and futimes + fsetattrlist so the file is opened only once? ------------- PR: https://git.openjdk.org/jdk/pull/11600 From duke at openjdk.org Sun Dec 11 12:56:07 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 Dec 2022 12:56:07 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16] In-Reply-To: References: Message-ID: On Sun, 10 Jul 2022 09:50:02 GMT, Markus KARG wrote: >> Markus KARG has updated the pull request incrementally with three additional commits since the last revision: >> >> - separate test class for each large file test >> - Base class only contains utilities and helpers >> - Renamed AbstractTransferTo to TransferToBase as it is not abstract > > Please keep this PR open; I will continune work on it soon. > @mkarg Do you have any benchmarks/results for the change? @AlanBateman It needed several months, but finally I found the time to provide the requested performance numbers: TransferToPerformance.inputStreamLoop 104857 thrpt 25 20557.862 ? 1539.845 ops/s TransferToPerformance.transferFrom 104857 thrpt 25 22093.131 ? 1178.483 ops/s TransferToPerformance.inputStreamLoop 1048576 thrpt 25 2366.391 ? 189.846 ops/s TransferToPerformance.transferFrom 1048576 thrpt 25 2553.160 ? 43.617 ops/s TransferToPerformance.inputStreamLoop 10485760 thrpt 25 197.128 ? 8.086 ops/s TransferToPerformance.transferFrom 10485760 thrpt 25 202.492 ? 6.436 ops/s These numbers undoubtedly proof that `transferFrom` is *always faster* than `InputStream::transferTo`'s original loop, for *all* tested stream lengths. > @mkarg I'm asking because FileChannel transferTo is implemented (where possible) on sendfile/equivalent so fast for the file -> socket and file -> file cases. The changes in this PR make use of FileChannel transferFrom so may not be significantly better than the default implementation. @AlanBateman The existing cases only covered file-to-something, while the current PR optimizes the reverse something-to-file way. As the above numbers proof that (why ever) `transferFrom` is *always faster* than the original loop of `InputStream::transferTo`, I will continue work on this PR ASAP. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Sun Dec 11 12:59:08 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 Dec 2022 12:59:08 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v7] In-Reply-To: References: <2w59bsBKnfKFrJQ9qVouh8ok9dY30h7GoAMs-n6Z8kw=.774e0672-1c41-4e90-ae7e-019b180f8449@github.com> Message-ID: <4mOlZjj_MTWuTKZlMlMaQ6wkvy-Rq1U03wKSJ94YO-A=.cc97f0e3-135e-4ddf-8328-7812474b70fa@github.com> On Wed, 22 Dec 2021 15:41:28 GMT, Alan Bateman wrote: >> Good catch! Silly me. Fixed in https://github.com/openjdk/jdk/pull/6711/commits/fc7d00bf20861276e11e755c6794999eca95049d. >> >> JDK-8278369: Tried several times on my Windows 11 laptop, but still cannot reproduce. Maybe Lance's boxes are simply overloaded / too slow? > >> JDK-8278369: Tried several times on my Windows 11 laptop, but still cannot reproduce. Maybe Lance's boxes are simply overloaded / too slow? > > I don't know if anyone has reproduced locally, instead it seems to be random Windows machines in our CI. There are differences between Windows client and server editions that periodically cause issues, I don't know if this is the case here. @LanceAndersen AFAIK the problem was not originally caused by this PR itself, but in fact by a problem inside of Windows, and recent JDKs workaround that problem somehow meanwhile. So it should be safe to continue with this PR now. If I am wrong please let me know. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Sun Dec 11 15:18:54 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 Dec 2022 15:18:54 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v17] In-Reply-To: References: Message-ID: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com> > This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel. Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Implementing 8278268 Signed-off-by: Markus Karg ------------- Changes: https://git.openjdk.org/jdk/pull/6711/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=6711&range=16 Stats: 804 lines in 6 files changed: 574 ins; 199 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/6711.diff Fetch: git fetch https://git.openjdk.org/jdk pull/6711/head:pull/6711 PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Sun Dec 11 15:22:25 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 Dec 2022 15:22:25 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v16] In-Reply-To: References: Message-ID: On Sun, 11 Dec 2022 12:54:04 GMT, Markus KARG wrote: >> Please keep this PR open; I will continune work on it soon. > >> @mkarg Do you have any benchmarks/results for the change? > > @AlanBateman It needed several months, but finally I found the time to provide the requested performance numbers: > > TransferToPerformance.inputStreamLoop 104857 thrpt 25 20557.862 ? 1539.845 ops/s > TransferToPerformance.transferFrom 104857 thrpt 25 22093.131 ? 1178.483 ops/s > > TransferToPerformance.inputStreamLoop 1048576 thrpt 25 2366.391 ? 189.846 ops/s > TransferToPerformance.transferFrom 1048576 thrpt 25 2553.160 ? 43.617 ops/s > > TransferToPerformance.inputStreamLoop 10485760 thrpt 25 197.128 ? 8.086 ops/s > TransferToPerformance.transferFrom 10485760 thrpt 25 202.492 ? 6.436 ops/s > > These numbers undoubtedly proof that `transferFrom` is *always faster* than `InputStream::transferTo`'s original loop, for *all* tested stream lengths. > >> @mkarg I'm asking because FileChannel transferTo is implemented (where possible) on sendfile/equivalent so fast for the file -> socket and file -> file cases. The changes in this PR make use of FileChannel transferFrom so may not be significantly better than the default implementation. > > @AlanBateman The existing cases only covered file-to-something, while the current PR optimizes the reverse something-to-file way. As the above numbers proof that (why ever) `transferFrom` is *always faster* than the original loop of `InputStream::transferTo`, I will continue work on this PR ASAP. > @mkarg Please do not rebase or force-push to an active PR as it invalidates existing review comments. Justification: I have updated this PR by rebasing the 8278268 branch ontop of the master branch. This was needed because the original code had merge conflicts, since it was originally authored ontop of JDK 18. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Sun Dec 11 15:27:40 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 11 Dec 2022 15:27:40 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v15] In-Reply-To: References: <4RcpFZMVKNqYuiowJOFwZuM_RDwKHAt8KyOPHz3S5c4=.23940329-cbf6-4f13-b044-eb91e4193f36@github.com> <3y4DdQ1hOUjOKWxuZ4JCwl9abqXbjqXpf-Awx9qLoek=.7d21aa99-9527-4c0f-b4a8-148073f98e71@github.com> Message-ID: On Mon, 10 Jan 2022 08:57:50 GMT, Alan Bateman wrote: >> @AlanBateman @LanceAndersen Back to the original thread of this PR, are there more change requests or is it fine for merging? > > @mkarg Do you have any benchmarks/results for the change? I'm asking because FileChannel transferTo is implemented (where possible) on sendfile/equivalent so fast for the file -> socket and file -> file cases. The changes in this PR make use of FileChannel transferFrom so may not be significantly better than the default implementation. @AlanBateman @LanceAndersen Kindly re-requesting review of this PR. Thanks! :-) ------------- PR: https://git.openjdk.org/jdk/pull/6711 From bpb at openjdk.org Mon Dec 12 19:16:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Dec 2022 19:16:06 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v2] In-Reply-To: References: Message-ID: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 7093322: Revise spec sentence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11616/files - new: https://git.openjdk.org/jdk/pull/11616/files/c0fda10f..20369045 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11616&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11616&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11616.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11616/head:pull/11616 PR: https://git.openjdk.org/jdk/pull/11616 From bpb at openjdk.org Mon Dec 12 19:16:07 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Dec 2022 19:16:07 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v2] In-Reply-To: References: Message-ID: On Sat, 10 Dec 2022 08:56:47 GMT, Alan Bateman wrote: > There isn't an "underlying stream" here but "file" could work. Alternatively, maybe this would work: Well there is a stream created internally but I guess that's an implementation detail we need not mention. > "Due to buffering, an IOException due to an encoding error (unmappable-character or malformed-input) may be thrown when writing, flushing or closing the buffered writer." Updated in 20369045bcba2fac3a34c5d6f7ac3f54e582eb3f. ------------- PR: https://git.openjdk.org/jdk/pull/11616 From alanb at openjdk.org Mon Dec 12 20:07:12 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Dec 2022 20:07:12 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v17] In-Reply-To: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com> References: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com> Message-ID: On Sun, 11 Dec 2022 15:18:54 GMT, Markus KARG wrote: >> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel. > > Markus KARG has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Implementing 8278268 > > Signed-off-by: Markus Karg Which platform was used to generate the performance data? Also what was the source stream? Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases. In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Mon Dec 12 20:45:08 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 12 Dec 2022 20:45:08 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v17] In-Reply-To: References: <1oBdzuvkxdvyCfCm4-8D_gOmHTihl5cxfQ4hEGuU_yE=.d6697a29-1850-40e6-b449-0078ad868081@github.com> Message-ID: On Mon, 12 Dec 2022 20:04:40 GMT, Alan Bateman wrote: > Which platform was used to generate the performance data? Ubuntu 20.04.5 LTS (x86_64) > Also what was the source stream? `Channels.newInputStream(Channels.newChannel(new ByteArrayInputStream(byte[size])))` > Just asking as FileChannel.transferFrom uses copy_file_range for file-to-file (Linux), memory mapping for file-to-file, and a copy loop for other cases. Yes, but apparently `FileChannel.transferFrom` is doing such copy loop more efficient than `InputStream.transferTo`'s loop. > In any case, the changes to ChannelInputStream.transferTo does the right thing. Most of the change in the PR is the tests. I don't have time to look at those closely right now but Lance or Brian might have cycles. Thanks. Please remember that the code was already reviewed and test-driven by Lance a year ago and just was held back due to the bug in Windows's Socket implementation, *discovered by* this PR's test. ------------- PR: https://git.openjdk.org/jdk/pull/6711 From djelinski at openjdk.org Mon Dec 12 20:48:31 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 12 Dec 2022 20:48:31 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket Message-ID: This patch reenables IPv6 stack when stdin is an IPv4 socket. The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. ------------- Commit messages: - Cleanup - Add bug ID - Use loopback instead of localhost - Add test - Allow IPv6 even if stdin is an IPv4 socket Changes: https://git.openjdk.org/jdk/pull/11638/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11638&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6914801 Stats: 196 lines in 7 files changed: 158 ins; 22 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/11638.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11638/head:pull/11638 PR: https://git.openjdk.org/jdk/pull/11638 From bpb at openjdk.org Mon Dec 12 22:23:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Dec 2022 22:23:06 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v3] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Avoid opening file more than once ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/a4ac9e75..ad14b579 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=01-02 Stats: 96 lines in 5 files changed: 58 ins; 14 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Mon Dec 12 22:23:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Dec 2022 22:23:06 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v2] In-Reply-To: <7oNFCCc7sDXIcEIrPNQi4MdFqvWCpTao77N4nKrMFuw=.7da409ff-e1cd-439b-926e-fee29c0b707d@github.com> References: <7oNFCCc7sDXIcEIrPNQi4MdFqvWCpTao77N4nKrMFuw=.7da409ff-e1cd-439b-926e-fee29c0b707d@github.com> Message-ID: On Sat, 10 Dec 2022 09:17:24 GMT, Alan Bateman wrote: > Could you look into using file.openForAttributeAccess(followLinks) and futimes + fsetattrlist so the file is opened only once? So changed in ad14b579cb865ee58e43c6fb4a35a779bfe4a578. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Mon Dec 12 22:30:36 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 12 Dec 2022 22:30:36 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v4] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Fix a comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/ad14b579..640a944f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From alanb at openjdk.org Tue Dec 13 08:13:57 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Dec 2022 08:13:57 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v2] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 19:16:06 GMT, Brian Burkhalter wrote: >> Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 7093322: Revise spec sentence Thanks for the update, the text is good now. You might want to bring back the links to write, flush and close as you had in the first version. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11616 From alanb at openjdk.org Tue Dec 13 10:15:27 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Dec 2022 10:15:27 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v4] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 22:30:36 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Fix a comment Updated version looks quite good, just a few minor nits. src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 57: > 55: fd = path.openForAttributeAccess(followLinks); > 56: } catch (UnixException x) { > 57: x.rethrowAsIOException(path); The try-open-catch shouldn't be nested in the other try-catch. If the open fails then the fd isn't closed and there is no suppressed exception. src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 98: > 96: } finally { > 97: Blocker.end(comp); > 98: } Can you check the formatting here, the end brace seems to be in pushed out. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From duke at openjdk.org Tue Dec 13 15:19:55 2022 From: duke at openjdk.org (Stewart X Addison) Date: Tue, 13 Dec 2022 15:19:55 GMT Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com> Message-ID: On Tue, 29 Nov 2022 11:19:37 GMT, Alan Bateman wrote: > Does it always fail on specific systems or it is intermittent? I have an AIX system that reproduces the problem (almost) 100% of the time. running your example repeatedly showsthe following - second timestamp always later than the first, although in some cases (The final one here and the third one) it's very close: bash-5.1$ while true; do jdk-19.0.1+10-jre/bin/java AlanBatemanWatchTest; echo =====; sleep 5; done 2022-12-13T15:14:40.634203242Z 2022-12-13T15:14:40.638408744Z ===== 2022-12-13T15:14:45.937219162Z 2022-12-13T15:14:45.944337962Z ===== 2022-12-13T15:14:51.23575265Z 2022-12-13T15:14:51.235752651Z ===== 2022-12-13T15:14:56.525754548Z 2022-12-13T15:14:56.53320089Z ===== 2022-12-13T15:15:01.816169292Z 2022-12-13T15:15:01.82617524Z ===== 2022-12-13T15:15:07.096153867Z 2022-12-13T15:15:07.096153868Z ===== 2022-12-13T15:15:12.366438085Z 2022-12-13T15:15:12.373201878Z ===== 2022-12-13T15:15:17.645776392Z 2022-12-13T15:15:17.645776393Z ===== ------------- PR: https://git.openjdk.org/jdk/pull/10824 From bpb at openjdk.org Tue Dec 13 16:41:57 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Dec 2022 16:41:57 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v3] In-Reply-To: References: Message-ID: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 7093322: Restore @linkplain instances ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11616/files - new: https://git.openjdk.org/jdk/pull/11616/files/20369045..b683c914 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11616&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11616&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11616.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11616/head:pull/11616 PR: https://git.openjdk.org/jdk/pull/11616 From bpb at openjdk.org Tue Dec 13 16:41:57 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Dec 2022 16:41:57 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v2] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 08:11:54 GMT, Alan Bateman wrote: > Thanks for the update, the text is good now. You might want to bring back the links to write, flush and close as you had in the first version. Links restore in b683c914748f311457fee7ad107c8580013884b7. ------------- PR: https://git.openjdk.org/jdk/pull/11616 From bpb at openjdk.org Tue Dec 13 17:13:18 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Dec 2022 17:13:18 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v5] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Clean up try-open-catch block, formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/640a944f..d9606e74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=03-04 Stats: 7 lines in 2 files changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Tue Dec 13 17:13:21 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 13 Dec 2022 17:13:21 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v4] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 10:10:59 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298187: Fix a comment > > src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 57: > >> 55: fd = path.openForAttributeAccess(followLinks); >> 56: } catch (UnixException x) { >> 57: x.rethrowAsIOException(path); > > The try-open-catch shouldn't be nested in the other try-catch. If the open fails there is no fd to close and no suppressed exception to add. Corrected in d9606e74d1869c3f548a6b7c6bef12b2c1e005ac. > src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 98: > >> 96: } finally { >> 97: Blocker.end(comp); >> 98: } > > Can you check the formatting here, the end brace seems to be in pushed out. Corrected in d9606e74d1869c3f548a6b7c6bef12b2c1e005ac. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From alanb at openjdk.org Tue Dec 13 19:29:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Dec 2022 19:29:58 GMT Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com> Message-ID: On Tue, 13 Dec 2022 15:17:23 GMT, Stewart X Addison wrote: >>> > Would it be possible to run this on the AIX system and paste in the output? >>> >>> On AIX: >>> >>> ``` >>> 2022-11-28T16:12:18.277871263Z >>> 2022-11-28T16:12:18.281290513Z >>> ``` >> >> Okay, so this means you've got high precision on the last modification time. So for these values it means that registering the directory will read initial time stamp as "2022-11-28T16:12:18.277871263Z", recording it in milliseconds. The file is modified (append in the example) and a short time later the WatchService should read the time stamp as "022-11-28T16:12:18.281290513Z", see that it has changed, and queue ENTRY_MODIFY event. So now I think we are back to why this is not happening on some AIX systems. Does it always fail on specific systems or it is intermittent? Any mount options or other config that enables or disables higher precision time stamps? > >> Does it always fail on specific systems or it is intermittent? > > I have an AIX system that reproduces the problem (almost) 100% of the time. Running your example repeatedly shows the following - second timestamp always later than the first, although in some cases (The final one here and the third one) it's very close: > > bash-5.1$ while true; do jdk-19.0.1+10-jre/bin/java AlanBatemanWatchTest; echo =====; sleep 5; done > 2022-12-13T15:14:40.634203242Z > 2022-12-13T15:14:40.638408744Z > ===== > 2022-12-13T15:14:45.937219162Z > 2022-12-13T15:14:45.944337962Z > ===== > 2022-12-13T15:14:51.23575265Z > 2022-12-13T15:14:51.235752651Z > ===== > 2022-12-13T15:14:56.525754548Z > 2022-12-13T15:14:56.53320089Z > ===== > 2022-12-13T15:15:01.816169292Z > 2022-12-13T15:15:01.82617524Z > ===== > 2022-12-13T15:15:07.096153867Z > 2022-12-13T15:15:07.096153868Z > ===== > 2022-12-13T15:15:12.366438085Z > 2022-12-13T15:15:12.373201878Z > ===== > 2022-12-13T15:15:17.645776392Z > 2022-12-13T15:15:17.645776393Z > ===== @sxa Would it be possible to try the following patch to record the timestamps as Instants rather than milliseconds as I suspect the issue is that milliseconds isn't precision enough for these systems. The test that is leading to the discussion here needs improving too but that's another issue. Running with this patch will help tell us if this is the issue you are running into but it's not the right change as file times can be outside of the range supported by Instant but it should be good enough for testing. diff --git a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java index f86626d196a..ce0f937bb1a 100644 --- a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java +++ b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java @@ -41,6 +41,7 @@ import java.security.PrivilegedAction; import java.security.PrivilegedExceptionAction; import java.security.PrivilegedActionException; import java.io.IOException; +import java.time.Instant; import java.util.HashMap; import java.util.HashSet; import java.util.Iterator; @@ -51,6 +52,7 @@ import java.util.concurrent.ScheduledExecutorService; import java.util.concurrent.ScheduledFuture; import java.util.concurrent.ThreadFactory; import java.util.concurrent.TimeUnit; +import static java.nio.file.LinkOption.NOFOLLOW_LINKS; /** * Simple WatchService implementation that uses periodic tasks to poll @@ -220,10 +222,10 @@ class PollingWatchService * Entry in directory cache to record file last-modified-time and tick-count */ private static class CacheEntry { - private long lastModified; + private Instant lastModified; private int lastTickCount; - CacheEntry(long lastModified, int lastTickCount) { + CacheEntry(Instant lastModified, int lastTickCount) { this.lastModified = lastModified; this.lastTickCount = lastTickCount; } @@ -232,11 +234,11 @@ class PollingWatchService return lastTickCount; } - long lastModified() { + Instant lastModified() { return lastModified; } - void update(long lastModified, int tickCount) { + void update(Instant lastModified, int tickCount) { this.lastModified = lastModified; this.lastTickCount = tickCount; } @@ -278,8 +280,7 @@ class PollingWatchService try (DirectoryStream stream = Files.newDirectoryStream(dir)) { for (Path entry: stream) { // don't follow links - long lastModified = - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); + Instant lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); } } catch (DirectoryIteratorException e) { @@ -356,10 +357,9 @@ class PollingWatchService // iterate over all entries in directory try { for (Path entry: stream) { - long lastModified = 0L; + Instant lastModified; try { - lastModified = - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); + lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); } catch (IOException x) { // unable to get attributes of entry. If file has just // been deleted then we'll report it as deleted on the @@ -371,8 +371,7 @@ class PollingWatchService CacheEntry e = entries.get(entry.getFileName()); if (e == null) { // new file found - entries.put(entry.getFileName(), - new CacheEntry(lastModified, tickCount)); + entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); // queue ENTRY_CREATE if event enabled if (events.contains(StandardWatchEventKinds.ENTRY_CREATE)) { @@ -391,7 +390,7 @@ class PollingWatchService } // check if file has changed - if (e.lastModified != lastModified) { + if (!e.lastModified().equals(lastModified)) { if (events.contains(StandardWatchEventKinds.ENTRY_MODIFY)) { signalEvent(StandardWatchEventKinds.ENTRY_MODIFY, entry.getFileName()); ------------- PR: https://git.openjdk.org/jdk/pull/10824 From alanb at openjdk.org Tue Dec 13 19:44:05 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Dec 2022 19:44:05 GMT Subject: RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected [v3] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 16:41:57 GMT, Brian Burkhalter wrote: >> Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 7093322: Restore @linkplain instances Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11616 From alanb at openjdk.org Tue Dec 13 20:04:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Dec 2022 20:04:21 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v5] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 17:13:18 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Clean up try-open-catch block, formatting Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11600 From mennen at openjdk.org Wed Dec 14 03:47:06 2022 From: mennen at openjdk.org (Michael Ennen) Date: Wed, 14 Dec 2022 03:47:06 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: <91WlM45Ykemls6D5vtXZMIIqjjECQTLVuJFhTLYXq-I=.4e670ac0-f1ff-480e-b18e-cea98d01bd6f@github.com> On Mon, 5 Dec 2022 13:46:09 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Preview annotation for JEP 434 > > Note: there are 4 tests failing in x86: > * MemoryLayoutPrincipalTotalityTest > * MemoryLayoutTypeRetentionTest > * TestLargeSegmentCopy > * TestLinker > > These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes @mcimadamore This PR made my code in [java-vulkan](https://github.com/brcolow/java-vulkan/commit/171f167782eea538b19b60d5fa73e9f75a112f6d) much cleaner! Nice work! ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Wed Dec 14 16:42:07 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Dec 2022 16:42:07 GMT Subject: RFR: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Message-ID: PollingWatchService currently records the last modified time of files in milliseconds. It would be better to just record the FileTime to avoid truncating high precision timestamps to millis. It's possible this change may also help JDK-8297275. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/11665/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11665&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298726 Stats: 15 lines in 1 file changed: 2 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11665.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11665/head:pull/11665 PR: https://git.openjdk.org/jdk/pull/11665 From bpb at openjdk.org Wed Dec 14 17:14:09 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Dec 2022 17:14:09 GMT Subject: RFR: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 09:30:56 GMT, Alan Bateman wrote: > PollingWatchService currently records the last modified time of files in milliseconds. It would be better to just record the FileTime to avoid truncating high precision timestamps to millis. > > It's possible this change may also help JDK-8297275. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11665 From bpb at openjdk.org Wed Dec 14 18:25:00 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Dec 2022 18:25:00 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v6] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Fix symbolic link case when links not followed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/d9606e74..aa3182da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=04-05 Stats: 108 lines in 3 files changed: 84 ins; 7 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Wed Dec 14 18:25:05 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 14 Dec 2022 18:25:05 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v5] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 17:13:18 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Clean up try-open-catch block, formatting `lutimes` must be used if the target is a link and links are _not_ being followed. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Thu Dec 15 02:34:59 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 02:34:59 GMT Subject: [jdk20] RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Message-ID: Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. ------------- Commit messages: - 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Changes: https://git.openjdk.org/jdk20/pull/36/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=36&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7093322 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk20/pull/36.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/36/head:pull/36 PR: https://git.openjdk.org/jdk20/pull/36 From jpai at openjdk.org Thu Dec 15 05:36:03 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Dec 2022 05:36:03 GMT Subject: RFR: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 09:30:56 GMT, Alan Bateman wrote: > PollingWatchService currently records the last modified time of files in milliseconds. It would be better to just record the FileTime to avoid truncating high precision timestamps to millis. > > It's possible this change may also help JDK-8297275. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11665 From alanb at openjdk.org Thu Dec 15 07:17:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Dec 2022 07:17:11 GMT Subject: Integrated: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds In-Reply-To: References: Message-ID: <9LznOPLrs-xzK-2EVp1D-a4eea3gvDMIts9RCeWqA_A=.bc716aa1-f8b3-4e03-b50f-b5f8ac281a39@github.com> On Wed, 14 Dec 2022 09:30:56 GMT, Alan Bateman wrote: > PollingWatchService currently records the last modified time of files in milliseconds. It would be better to just record the FileTime to avoid truncating high precision timestamps to millis. > > It's possible this change may also help JDK-8297275. This pull request has now been integrated. Changeset: 5f63f7a7 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/5f63f7a742a1071a87ca69463bae6e04a44fe462 Stats: 15 lines in 1 file changed: 2 ins; 4 del; 9 mod 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Reviewed-by: bpb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11665 From alanb at openjdk.org Thu Dec 15 07:51:13 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Dec 2022 07:51:13 GMT Subject: [jdk20] RFR: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 02:28:46 GMT, Brian Burkhalter wrote: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/36 From alanb at openjdk.org Thu Dec 15 14:46:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Dec 2022 14:46:11 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v6] In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 18:25:00 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Fix symbolic link case when links not followed Marked as reviewed by alanb (Reviewer). src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 100: > 98: futimens(fd, accessValue, modValue); > 99: } catch (UnixException x) { > 100: // if futimens fails with EINVAL and one/both of the times is The comment should probably say "lutimes/futimens". ------------- PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Thu Dec 15 17:30:14 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 17:30:14 GMT Subject: [jdk20] Integrated: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 02:28:46 GMT, Brian Burkhalter wrote: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. This pull request has now been integrated. Changeset: ca39eb90 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk20/commit/ca39eb906692568347e7f264520593188f9276cf Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk20/pull/36 From bpb at openjdk.org Thu Dec 15 17:31:09 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 17:31:09 GMT Subject: Integrated: 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 20:28:31 GMT, Brian Burkhalter wrote: > Add a sentence to clarify that coding exceptions are not thrown until the characters are actually written to the underlying stream. This pull request has now been integrated. Changeset: 831b35fa Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/831b35fad352887717d5cc8f001ad822ac9a5c46 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 7093322: (fs spec) Files.newBufferedWriter should be clear when coding errors are detected Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/11616 From bpb at openjdk.org Thu Dec 15 17:35:40 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 17:35:40 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v7] In-Reply-To: References: Message-ID: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8298187: Modify internal comment to include lutimes(3) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11600/files - new: https://git.openjdk.org/jdk/pull/11600/files/aa3182da..fc589d20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11600&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11600.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11600/head:pull/11600 PR: https://git.openjdk.org/jdk/pull/11600 From bpb at openjdk.org Thu Dec 15 17:35:41 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 17:35:41 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v6] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 14:43:44 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8298187: Fix symbolic link case when links not followed > > src/java.base/macosx/classes/sun/nio/fs/BsdFileAttributeViews.java line 100: > >> 98: futimens(fd, accessValue, modValue); >> 99: } catch (UnixException x) { >> 100: // if futimens fails with EINVAL and one/both of the times is > > The comment should probably say "lutimes/futimens". Comment modified in fc589d209bd60a63eb7935ced2be776e12ca223e. ------------- PR: https://git.openjdk.org/jdk/pull/11600 From alanb at openjdk.org Thu Dec 15 17:58:10 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Dec 2022 17:58:10 GMT Subject: RFR: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ [v7] In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 17:35:40 GMT, Brian Burkhalter wrote: >> If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8298187: Modify internal comment to include lutimes(3) Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11600 From alanb at openjdk.org Thu Dec 15 18:13:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Dec 2022 18:13:06 GMT Subject: RFR: 6914801: IPv6 unavailable if stdin is a socket In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 20:30:05 GMT, Daniel Jeli?ski wrote: > This patch reenables IPv6 stack when stdin is an IPv4 socket. > > The code that blocked IPv6 was introduced in JDK-4673940 back when JDK could only operate with either IPv4 or IPv6 sockets, and was using `IPv6_available` to determine which socket type was in use. Now that JDK is able to operate with both IPv4 and IPv6 sockets at the same time, the check for IPv4 stdin is no longer relevant. > > Included test passes with the changes applied, fails without them. Other tier1-3 tests also pass. I don't have time to study the tests right now but the src change look okay. ------------- PR: https://git.openjdk.org/jdk/pull/11638 From bpb at openjdk.org Thu Dec 15 22:51:10 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 22:51:10 GMT Subject: Integrated: 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:13:03 GMT, Brian Burkhalter wrote: > If the path is on an HFS store, use the generic Unix implementation of `java.nio.file.attribute.BasicFileAttributeView::setTimes`to set the last access time. This pull request has now been integrated. Changeset: 54124394 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/5412439445fadcf66101018a9bd051f8e5d751e8 Stats: 164 lines in 5 files changed: 129 ins; 12 del; 23 mod 8298187: (fs) BsdFileAttributeViews::setTimes does not support lastAccessTime on HFS+ Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/11600 From duke at openjdk.org Mon Dec 19 15:23:50 2022 From: duke at openjdk.org (Stewart X Addison) Date: Mon, 19 Dec 2022 15:23:50 GMT Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com> Message-ID: On Tue, 13 Dec 2022 19:27:28 GMT, Alan Bateman wrote: >>> Does it always fail on specific systems or it is intermittent? >> >> I have an AIX system that reproduces the problem (almost) 100% of the time. Running your example repeatedly shows the following - second timestamp always later than the first, although in some cases (The final one here and the third one) it's very close: >> >> bash-5.1$ while true; do jdk-19.0.1+10-jre/bin/java AlanBatemanWatchTest; echo =====; sleep 5; done >> 2022-12-13T15:14:40.634203242Z >> 2022-12-13T15:14:40.638408744Z >> ===== >> 2022-12-13T15:14:45.937219162Z >> 2022-12-13T15:14:45.944337962Z >> ===== >> 2022-12-13T15:14:51.23575265Z >> 2022-12-13T15:14:51.235752651Z >> ===== >> 2022-12-13T15:14:56.525754548Z >> 2022-12-13T15:14:56.53320089Z >> ===== >> 2022-12-13T15:15:01.816169292Z >> 2022-12-13T15:15:01.82617524Z >> ===== >> 2022-12-13T15:15:07.096153867Z >> 2022-12-13T15:15:07.096153868Z >> ===== >> 2022-12-13T15:15:12.366438085Z >> 2022-12-13T15:15:12.373201878Z >> ===== >> 2022-12-13T15:15:17.645776392Z >> 2022-12-13T15:15:17.645776393Z >> ===== > > @sxa Would it be possible to try the following patch to record the timestamps as Instants rather than milliseconds as I suspect the issue is that milliseconds isn't precision enough for these systems. The test that is leading to the discussion here needs improving too but that's another issue. Running with this patch will help tell us if this is the issue you are running into but it's not the right change as file times can be outside of the range supported by Instant but it should be good enough for testing. > > > diff --git a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > index f86626d196a..ce0f937bb1a 100644 > --- a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > +++ b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > @@ -41,6 +41,7 @@ import java.security.PrivilegedAction; > import java.security.PrivilegedExceptionAction; > import java.security.PrivilegedActionException; > import java.io.IOException; > +import java.time.Instant; > import java.util.HashMap; > import java.util.HashSet; > import java.util.Iterator; > @@ -51,6 +52,7 @@ import java.util.concurrent.ScheduledExecutorService; > import java.util.concurrent.ScheduledFuture; > import java.util.concurrent.ThreadFactory; > import java.util.concurrent.TimeUnit; > +import static java.nio.file.LinkOption.NOFOLLOW_LINKS; > > /** > * Simple WatchService implementation that uses periodic tasks to poll > @@ -220,10 +222,10 @@ class PollingWatchService > * Entry in directory cache to record file last-modified-time and tick-count > */ > private static class CacheEntry { > - private long lastModified; > + private Instant lastModified; > private int lastTickCount; > > - CacheEntry(long lastModified, int lastTickCount) { > + CacheEntry(Instant lastModified, int lastTickCount) { > this.lastModified = lastModified; > this.lastTickCount = lastTickCount; > } > @@ -232,11 +234,11 @@ class PollingWatchService > return lastTickCount; > } > > - long lastModified() { > + Instant lastModified() { > return lastModified; > } > > - void update(long lastModified, int tickCount) { > + void update(Instant lastModified, int tickCount) { > this.lastModified = lastModified; > this.lastTickCount = tickCount; > } > @@ -278,8 +280,7 @@ class PollingWatchService > try (DirectoryStream stream = Files.newDirectoryStream(dir)) { > for (Path entry: stream) { > // don't follow links > - long lastModified = > - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); > + Instant lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); > entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); > } > } catch (DirectoryIteratorException e) { > @@ -356,10 +357,9 @@ class PollingWatchService > // iterate over all entries in directory > try { > for (Path entry: stream) { > - long lastModified = 0L; > + Instant lastModified; > try { > - lastModified = > - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); > + lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); > } catch (IOException x) { > // unable to get attributes of entry. If file has just > // been deleted then we'll report it as deleted on the > @@ -371,8 +371,7 @@ class PollingWatchService > CacheEntry e = entries.get(entry.getFileName()); > if (e == null) { > // new file found > - entries.put(entry.getFileName(), > - new CacheEntry(lastModified, tickCount)); > + entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); > > // queue ENTRY_CREATE if event enabled > if (events.contains(StandardWatchEventKinds.ENTRY_CREATE)) { > @@ -391,7 +390,7 @@ class PollingWatchService > } > > // check if file has changed > - if (e.lastModified != lastModified) { > + if (!e.lastModified().equals(lastModified)) { > if (events.contains(StandardWatchEventKinds.ENTRY_MODIFY)) { > signalEvent(StandardWatchEventKinds.ENTRY_MODIFY, > entry.getFileName()); > > > Update: PR 11665 is now integrated so the last modified time is recorded as a FileTime. It would be good to test with main line to see if you still observe the issue. @AlanBateman I'm building both options now, but so far 6 attempts with #11665 are looking positive! (I've had to put that fix on top of an older SHA since I'm having problems building the latest code despite @backwaterred's fix at https://github.com/openjdk/jdk/pull/11443 ------------- PR: https://git.openjdk.org/jdk/pull/10824 From duke at openjdk.org Tue Dec 20 08:47:52 2022 From: duke at openjdk.org (Markus KARG) Date: Tue, 20 Dec 2022 08:47:52 GMT Subject: RFR: 8278268 - (ch) InputStream returned by Channels.newInputStream should have fast path for FileChannel targets [v8] In-Reply-To: References: Message-ID: On Sun, 2 Jan 2022 21:56:59 GMT, Lance Andersen wrote: >>> @LanceAndersen I assumed the second test will exist only for the time until we fixed the Windows problems, so I did not invest time to reduce duplication so far. So you really want to keep the separated tests forever and want me to reduce duplication? >> >> I would not make any such assumptions especially for tests that create large files. So yes please address the duplication. It is not a huge amount of work to create a base class that the tests extend (you will see examples elsewhere within the various test directories). > >> @LanceAndersen I'm done with the requested changes. For "the remaining tests" I kept the separation into TransferTo (existing tests) and TransferTo2 (new tests of this PR) -- or do you want me to consolidate TransferTo2 into TransferTo now that Alan identified the source of trouble being the Unix Domain Sockets? > > I haven't gone through this in detail, but we want to merge The remaining TransferTo2 tests into TransferTo. For the large File tests, any duplicate code can also be included in the base class. > > I will look at this more when I am back from the holiday break @LanceAndersen "Ping" :-) ------------- PR: https://git.openjdk.org/jdk/pull/6711 From duke at openjdk.org Tue Dec 20 15:37:50 2022 From: duke at openjdk.org (Stewart X Addison) Date: Tue, 20 Dec 2022 15:37:50 GMT Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: <-tPn-83pafiAnATErF8OLTLR7BetQ77vdamo4UOofXQ=.69337422-e19c-45bb-bd0a-60fff93094de@github.com> Message-ID: On Tue, 13 Dec 2022 19:27:28 GMT, Alan Bateman wrote: >>> Does it always fail on specific systems or it is intermittent? >> >> I have an AIX system that reproduces the problem (almost) 100% of the time. Running your example repeatedly shows the following - second timestamp always later than the first, although in some cases (The final one here and the third one) it's very close: >> >> bash-5.1$ while true; do jdk-19.0.1+10-jre/bin/java AlanBatemanWatchTest; echo =====; sleep 5; done >> 2022-12-13T15:14:40.634203242Z >> 2022-12-13T15:14:40.638408744Z >> ===== >> 2022-12-13T15:14:45.937219162Z >> 2022-12-13T15:14:45.944337962Z >> ===== >> 2022-12-13T15:14:51.23575265Z >> 2022-12-13T15:14:51.235752651Z >> ===== >> 2022-12-13T15:14:56.525754548Z >> 2022-12-13T15:14:56.53320089Z >> ===== >> 2022-12-13T15:15:01.816169292Z >> 2022-12-13T15:15:01.82617524Z >> ===== >> 2022-12-13T15:15:07.096153867Z >> 2022-12-13T15:15:07.096153868Z >> ===== >> 2022-12-13T15:15:12.366438085Z >> 2022-12-13T15:15:12.373201878Z >> ===== >> 2022-12-13T15:15:17.645776392Z >> 2022-12-13T15:15:17.645776393Z >> ===== > > @sxa Would it be possible to try the following patch to record the timestamps as Instants rather than milliseconds as I suspect the issue is that milliseconds isn't precision enough for these systems. The test that is leading to the discussion here needs improving too but that's another issue. Running with this patch will help tell us if this is the issue you are running into but it's not the right change as file times can be outside of the range supported by Instant but it should be good enough for testing. > > > diff --git a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > index f86626d196a..ce0f937bb1a 100644 > --- a/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > +++ b/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java > @@ -41,6 +41,7 @@ import java.security.PrivilegedAction; > import java.security.PrivilegedExceptionAction; > import java.security.PrivilegedActionException; > import java.io.IOException; > +import java.time.Instant; > import java.util.HashMap; > import java.util.HashSet; > import java.util.Iterator; > @@ -51,6 +52,7 @@ import java.util.concurrent.ScheduledExecutorService; > import java.util.concurrent.ScheduledFuture; > import java.util.concurrent.ThreadFactory; > import java.util.concurrent.TimeUnit; > +import static java.nio.file.LinkOption.NOFOLLOW_LINKS; > > /** > * Simple WatchService implementation that uses periodic tasks to poll > @@ -220,10 +222,10 @@ class PollingWatchService > * Entry in directory cache to record file last-modified-time and tick-count > */ > private static class CacheEntry { > - private long lastModified; > + private Instant lastModified; > private int lastTickCount; > > - CacheEntry(long lastModified, int lastTickCount) { > + CacheEntry(Instant lastModified, int lastTickCount) { > this.lastModified = lastModified; > this.lastTickCount = lastTickCount; > } > @@ -232,11 +234,11 @@ class PollingWatchService > return lastTickCount; > } > > - long lastModified() { > + Instant lastModified() { > return lastModified; > } > > - void update(long lastModified, int tickCount) { > + void update(Instant lastModified, int tickCount) { > this.lastModified = lastModified; > this.lastTickCount = tickCount; > } > @@ -278,8 +280,7 @@ class PollingWatchService > try (DirectoryStream stream = Files.newDirectoryStream(dir)) { > for (Path entry: stream) { > // don't follow links > - long lastModified = > - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); > + Instant lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); > entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); > } > } catch (DirectoryIteratorException e) { > @@ -356,10 +357,9 @@ class PollingWatchService > // iterate over all entries in directory > try { > for (Path entry: stream) { > - long lastModified = 0L; > + Instant lastModified; > try { > - lastModified = > - Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS).toMillis(); > + lastModified = Files.getLastModifiedTime(entry, NOFOLLOW_LINKS).toInstant(); > } catch (IOException x) { > // unable to get attributes of entry. If file has just > // been deleted then we'll report it as deleted on the > @@ -371,8 +371,7 @@ class PollingWatchService > CacheEntry e = entries.get(entry.getFileName()); > if (e == null) { > // new file found > - entries.put(entry.getFileName(), > - new CacheEntry(lastModified, tickCount)); > + entries.put(entry.getFileName(), new CacheEntry(lastModified, tickCount)); > > // queue ENTRY_CREATE if event enabled > if (events.contains(StandardWatchEventKinds.ENTRY_CREATE)) { > @@ -391,7 +390,7 @@ class PollingWatchService > } > > // check if file has changed > - if (e.lastModified != lastModified) { > + if (!e.lastModified().equals(lastModified)) { > if (events.contains(StandardWatchEventKinds.ENTRY_MODIFY)) { > signalEvent(StandardWatchEventKinds.ENTRY_MODIFY, > entry.getFileName()); > > > Update: PR 11665 is now integrated so the last modified time is recorded as a FileTime. It would be good to test with main line to see if you still observe the issue. @AlanBateman I've submitted a backport for 11665 to jdk17u-dev since that's looking positive: https://github.com/openjdk/jdk17u-dev/pull/957 What's the process for getting it into jdk20? Can I just PR to `jdk20` in the absence of a `-dev` branch for it? ------------- PR: https://git.openjdk.org/jdk/pull/10824 From tsteele at openjdk.org Tue Dec 20 17:36:21 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 20 Dec 2022 17:36:21 GMT Subject: [jdk20] RFR: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Message-ID: This change fixes an issue with a jck test described in [JDK-8297275](https://bugs.openjdk.org/browse/JDK-8297275). The change applies cleanly. ------------- Commit messages: - Backport 5f63f7a742a1071a87ca69463bae6e04a44fe462 Changes: https://git.openjdk.org/jdk20/pull/64/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=64&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298726 Stats: 15 lines in 1 file changed: 2 ins; 4 del; 9 mod Patch: https://git.openjdk.org/jdk20/pull/64.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/64/head:pull/64 PR: https://git.openjdk.org/jdk20/pull/64 From tsteele at openjdk.org Tue Dec 20 22:59:59 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 20 Dec 2022 22:59:59 GMT Subject: RFR: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele wrote: > This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active. I am happy to see that #11665 fixes this issue. As such, this fix is no longer required. ------------- PR: https://git.openjdk.org/jdk/pull/10824 From tsteele at openjdk.org Tue Dec 20 22:59:59 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Tue, 20 Dec 2022 22:59:59 GMT Subject: Withdrawn: 8297275: WatchService delay with PollingWatchService causes test failures In-Reply-To: References: Message-ID: <9dcFGeS9k8R_PgZUaBa3NVd56Et4HG_BMJd-ntDnKHg=.c682aa23-03ca-41b7-b659-ab17565ebeaf@github.com> On Fri, 21 Oct 2022 21:43:25 GMT, Tyler Steele wrote: > This minor change fixes a compliance test failure which was partially addressed by https://github.com/openjdk/jdk/commit/1bb4de2e2868a539846ec48dd43fd623c2ba69a5. However the failure was still observed on select machines. This change addresses the remaining failures by ensuring that any new WatchKey is held until the polling thread becomes active. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10824 From aturbanov at openjdk.org Wed Dec 21 08:18:55 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 21 Dec 2022 08:18:55 GMT Subject: Integrated: 8297682: Use Collections.emptyIterator where applicable In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:30:20 GMT, Andrey Turbanov wrote: > Instead of `Collections.emptyList().iterator()` we can use `Collections.emptyIterator()` method. > Actual implementation of `java.util.Collections.EmptyList#iterator` does exactly this - just calls `emptyIterator` method. This pull request has now been integrated. Changeset: 85f9b37d Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/85f9b37d71852d35a75d404e1657db0562dacac5 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod 8297682: Use Collections.emptyIterator where applicable Reviewed-by: stsypanov, alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11025 From pminborg at openjdk.org Wed Dec 21 09:36:31 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 Dec 2022 09:36:31 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder Message-ID: This PR proposes to declare the field `ByteOrder.name` `final`. This will ensure the class is thread safe and is using safe publication. ------------- Commit messages: - Declare field name final Changes: https://git.openjdk.org/jdk/pull/11752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11752&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299187 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11752.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11752/head:pull/11752 PR: https://git.openjdk.org/jdk/pull/11752 From dholmes at openjdk.org Wed Dec 21 09:48:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Dec 2022 09:48:48 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder In-Reply-To: References: Message-ID: <1VQzcIRwvAA2yzi87vmmYqQdy5vYUc-NkV-sb8VQ3P8=.9bd44327-54f9-431b-8ad9-5de5fb7d3dfd@github.com> On Wed, 21 Dec 2022 09:29:59 GMT, Per Minborg wrote: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. This change is harmless but not strictly necessary. The only construction of ByteOrder instances is within the ByteOrder class as static final fields, hence class initialization semantics ensures they are safely published. ------------- PR: https://git.openjdk.org/jdk/pull/11752 From pminborg at openjdk.org Wed Dec 21 12:29:29 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 21 Dec 2022 12:29:29 GMT Subject: RFR: 8299193: Micro-optimization in Buffer Message-ID: This PR proposed a micro-optimization in Buffer. This change will benefit several subclasses as well. ------------- Commit messages: - Declare Buffer.capaity final Changes: https://git.openjdk.org/jdk/pull/11755/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11755&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299193 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11755.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11755/head:pull/11755 PR: https://git.openjdk.org/jdk/pull/11755 From rriggs at openjdk.org Wed Dec 21 14:55:50 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 Dec 2022 14:55:50 GMT Subject: RFR: 8299193: Micro-optimization in Buffer In-Reply-To: References: Message-ID: <5QM_ltXX93-LPJoVKC6Ga3X9kEsX5XvwZUtZJVcw-2M=.caaaec19-7d6d-4ce0-89d7-ed64da587484@github.com> On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > This PR proposed a micro-optimization in Buffer. This change will benefit several subclasses as well. LGTM; it would be enough to say it should be final. Posing this as an optimization leads one to wonder how much? ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11755 From tsteele at openjdk.org Wed Dec 21 18:21:00 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Wed, 21 Dec 2022 18:21:00 GMT Subject: [jdk20] RFR: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 17:29:30 GMT, Tyler Steele wrote: > This change fixes an issue with a jck test described in [JDK-8297275](https://bugs.openjdk.org/browse/JDK-8297275). The change applies cleanly. All testing successful. Merging as per the issue comments. ------------- PR: https://git.openjdk.org/jdk20/pull/64 From tsteele at openjdk.org Wed Dec 21 18:21:02 2022 From: tsteele at openjdk.org (Tyler Steele) Date: Wed, 21 Dec 2022 18:21:02 GMT Subject: [jdk20] Integrated: 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 17:29:30 GMT, Tyler Steele wrote: > This change fixes an issue with a jck test described in [JDK-8297275](https://bugs.openjdk.org/browse/JDK-8297275). The change applies cleanly. This pull request has now been integrated. Changeset: 9adc349c Author: Tyler Steele URL: https://git.openjdk.org/jdk20/commit/9adc349cbb38ccc23096c4504c7b4b70009c660f Stats: 15 lines in 1 file changed: 2 ins; 4 del; 9 mod 8298726: (fs) Change PollingWatchService to record last modified time as FileTime rather than milliseconds Backport-of: 5f63f7a742a1071a87ca69463bae6e04a44fe462 ------------- PR: https://git.openjdk.org/jdk20/pull/64 From duke at openjdk.org Wed Dec 21 21:07:50 2022 From: duke at openjdk.org (Decencies) Date: Wed, 21 Dec 2022 21:07:50 GMT Subject: RFR: 8299193: Micro-optimization in Buffer In-Reply-To: References: Message-ID: <_WeLhL9BIlz_-UAl5PtRPAHLirHBGjkHaNZL1BcwFM0=.dbed5a32-66f7-4e68-8fa9-3c7e353fd348@github.com> On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > This PR proposed a micro-optimization in Buffer. This change will benefit several subclasses as well. After pulling & compiling the JDK, I can see a noticeable improvement in NIO's Buffer performance. Thank you for discovering this optimization, I don't know what I would do if this optimization was not recognized and implemented into newer versions of the JDK. Thank you for the time and effort spent improving Java for developers like me! ------------- PR: https://git.openjdk.org/jdk/pull/11755 From dholmes at openjdk.org Wed Dec 21 23:55:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Dec 2022 23:55:49 GMT Subject: RFR: 8299193: Micro-optimization in Buffer In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > This PR proposed a micro-optimization in Buffer. This change will benefit several subclasses as well. I agree with Roger. If you're positioning this as a micro-optimization then you need to back it up with numbers, not just hope a final field improves something. The field should be final from a semantics point of view. ------------- PR: https://git.openjdk.org/jdk/pull/11755 From pminborg at openjdk.org Thu Dec 22 09:57:49 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 Dec 2022 09:57:49 GMT Subject: RFR: 8299193: Micro-optimization in Buffer In-Reply-To: References: Message-ID: <4Xe9LlmOdrayNY2frCP8PLivhUn5Ia8gfT6vokrPkA0=.404ce101-e431-49e7-8ee6-cd60ff9426a8@github.com> On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final`, potentially unlocking performance optimizations. The header in this PR was not exactly reflecting the initial bug report so I have updated it accordingly toning down any immediate performance gain guarantees. That said, we should add benchmarks to the PR. I will add them. ------------- PR: https://git.openjdk.org/jdk/pull/11755 From pminborg at openjdk.org Thu Dec 22 13:52:48 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 22 Dec 2022 13:52:48 GMT Subject: RFR: 8299193: Micro-optimization in Buffer In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final`, potentially unlocking performance optimizations. Benchmarking with and without `final` didn't affect performance noticeable when run under the current JVM implementation. Final | ? | ? | ? | ? | ? | ? -- | -- | -- | -- | -- | -- | -- Benchmark | (size) | Mode | Cnt | Score | Error | Units ByteBuffers.testDirectLoopGetByte | 16 | avgt | 30 | 4.517 | 0.027 | ns/op ByteBuffers.testDirectLoopGetByteRO | 16 | avgt | 30 | 4.461 | 0.019 | ns/op ByteBuffers.testDirectLoopGetByteSwap | 16 | avgt | 30 | 4.461 | 0.018 | ns/op ByteBuffers.testDirectLoopGetByteSwapRO | 16 | avgt | 30 | 4.465 | 0.024 | ns/op ByteBuffers.testDirectLoopGetChar | 16 | avgt | 30 | 4.455 | 0.012 | ns/op ByteBuffers.testDirectLoopGetCharRO | 16 | avgt | 30 | 4.442 | 0.013 | ns/op ByteBuffers.testDirectLoopGetCharSwap | 16 | avgt | 30 | 3.994 | 0.01 | ns/op ByteBuffers.testDirectLoopGetCharSwapRO | 16 | avgt | 30 | 4.43 | 0.005 | ns/op ByteBuffers.testDirectLoopGetDouble | 16 | avgt | 30 | 2.779 | 0.016 | ns/op ByteBuffers.testDirectLoopGetDoubleRO | 16 | avgt | 30 | 2.756 | 0.008 | ns/op ByteBuffers.testDirectLoopGetDoubleSwap | 16 | avgt | 30 | 2.762 | 0.015 | ns/op ByteBuffers.testDirectLoopGetDoubleSwapRO | 16 | avgt | 30 | 2.783 | 0.019 | ns/op ByteBuffers.testDirectLoopGetFloat | 16 | avgt | 30 | 3.237 | 0.019 | ns/op ByteBuffers.testDirectLoopGetFloatRO | 16 | avgt | 30 | 3.224 | 0.01 | ns/op ByteBuffers.testDirectLoopGetFloatSwap | 16 | avgt | 30 | 3.163 | 0.004 | ns/op ByteBuffers.testDirectLoopGetFloatSwapRO | 16 | avgt | 30 | 3.24 | 0.028 | ns/op ByteBuffers.testDirectLoopGetInt | 16 | avgt | 30 | 3.141 | 0.01 | ns/op ByteBuffers.testDirectLoopGetIntRO | 16 | avgt | 30 | 3.128 | 0.007 | ns/op ByteBuffers.testDirectLoopGetIntSwap | 16 | avgt | 30 | 3.166 | 0.018 | ns/op ByteBuffers.testDirectLoopGetIntSwapRO | 16 | avgt | 30 | 3.214 | 0.122 | ns/op ByteBuffers.testDirectLoopGetLong | 16 | avgt | 30 | 2.784 | 0.011 | ns/op ByteBuffers.testDirectLoopGetLongRO | 16 | avgt | 30 | 2.778 | 0.013 | ns/op ByteBuffers.testDirectLoopGetLongSwap | 16 | avgt | 30 | 2.788 | 0.007 | ns/op ByteBuffers.testDirectLoopGetLongSwapRO | 16 | avgt | 30 | 2.771 | 0.005 | ns/op ByteBuffers.testDirectLoopGetShort | 16 | avgt | 30 | 5.017 | 0.037 | ns/op ByteBuffers.testDirectLoopGetShortRO | 16 | avgt | 30 | 4.982 | 0.006 | ns/op ByteBuffers.testDirectLoopGetShortSwap | 16 | avgt | 30 | 4.01 | 0.031 | ns/op ByteBuffers.testDirectLoopGetShortSwapRO | 16 | avgt | 30 | 5.017 | 0.052 | ns/op ByteBuffers.testDirectLoopPutByte | 16 | avgt | 30 | 4.381 | 0.017 | ns/op ByteBuffers.testDirectLoopPutByteSwap | 16 | avgt | 30 | 4.404 | 0.029 | ns/op ByteBuffers.testDirectLoopPutChar | 16 | avgt | 30 | 3.981 | 0.019 | ns/op ByteBuffers.testDirectLoopPutCharSwap | 16 | avgt | 30 | 3.951 | 0.006 | ns/op ByteBuffers.testDirectLoopPutDouble | 16 | avgt | 30 | 2.798 | 0.009 | ns/op ByteBuffers.testDirectLoopPutDoubleSwap | 16 | avgt | 30 | 2.816 | 0.016 | ns/op ByteBuffers.testDirectLoopPutFloat | 16 | avgt | 30 | 3.127 | 0.005 | ns/op ByteBuffers.testDirectLoopPutFloatSwap | 16 | avgt | 30 | 3.185 | 0.075 | ns/op ByteBuffers.testDirectLoopPutInt | 16 | avgt | 30 | 3.233 | 0.05 | ns/op ByteBuffers.testDirectLoopPutIntSwap | 16 | avgt | 30 | 3.182 | 0.022 | ns/op ByteBuffers.testDirectLoopPutLong | 16 | avgt | 30 | 2.768 | 0.029 | ns/op ByteBuffers.testDirectLoopPutLongSwap | 16 | avgt | 30 | 2.746 | 0.003 | ns/op ByteBuffers.testDirectLoopPutShort | 16 | avgt | 30 | 3.981 | 0.006 | ns/op ByteBuffers.testDirectLoopPutShortSwap | 16 | avgt | 30 | 3.959 | 0.015 | ns/op ByteBuffers.testHeapBulkGetByte | 16 | avgt | 30 | 2.547 | 0.02 | ns/op ByteBuffers.testHeapBulkPutByte | 16 | avgt | 30 | 2.532 | 0.023 | ns/op ByteBuffers.testHeapLoopGetByte | 16 | avgt | 30 | 5.974 | 0.07 | ns/op ByteBuffers.testHeapLoopGetByteRO | 16 | avgt | 30 | 6.006 | 0.252 | ns/op ByteBuffers.testHeapLoopGetByteSwap | 16 | avgt | 30 | 5.878 | 0.019 | ns/op ByteBuffers.testHeapLoopGetByteSwapRO | 16 | avgt | 30 | 6.086 | 0.026 | ns/op ByteBuffers.testHeapLoopGetChar | 16 | avgt | 30 | 4.847 | 0.051 | ns/op ByteBuffers.testHeapLoopGetCharRO | 16 | avgt | 30 | 4.729 | 0.014 | ns/op ByteBuffers.testHeapLoopGetCharSwap | 16 | avgt | 30 | 4.204 | 0.028 | ns/op ByteBuffers.testHeapLoopGetCharSwapRO | 16 | avgt | 30 | 4.677 | 0.005 | ns/op ByteBuffers.testHeapLoopGetDouble | 16 | avgt | 30 | 2.971 | 0.011 | ns/op ByteBuffers.testHeapLoopGetDoubleRO | 16 | avgt | 30 | 2.968 | 0.012 | ns/op ByteBuffers.testHeapLoopGetDoubleSwap | 16 | avgt | 30 | 2.915 | 0.005 | ns/op ByteBuffers.testHeapLoopGetDoubleSwapRO | 16 | avgt | 30 | 2.968 | 0.013 | ns/op ByteBuffers.testHeapLoopGetFloat | 16 | avgt | 30 | 3.32 | 0.003 | ns/op ByteBuffers.testHeapLoopGetFloatRO | 16 | avgt | 30 | 3.32 | 0.005 | ns/op ByteBuffers.testHeapLoopGetFloatSwap | 16 | avgt | 30 | 3.317 | 0.004 | ns/op ByteBuffers.testHeapLoopGetFloatSwapRO | 16 | avgt | 30 | 3.32 | 0.003 | ns/op ByteBuffers.testHeapLoopGetInt | 16 | avgt | 30 | 3.315 | 0.004 | ns/op ByteBuffers.testHeapLoopGetIntRO | 16 | avgt | 30 | 3.316 | 0.003 | ns/op ByteBuffers.testHeapLoopGetIntSwap | 16 | avgt | 30 | 3.317 | 0.004 | ns/op ByteBuffers.testHeapLoopGetIntSwapRO | 16 | avgt | 30 | 3.319 | 0.008 | ns/op ByteBuffers.testHeapLoopGetLong | 16 | avgt | 30 | 2.927 | 0.004 | ns/op ByteBuffers.testHeapLoopGetLongRO | 16 | avgt | 30 | 2.928 | 0.005 | ns/op ByteBuffers.testHeapLoopGetLongSwap | 16 | avgt | 30 | 2.911 | 0.003 | ns/op ByteBuffers.testHeapLoopGetLongSwapRO | 16 | avgt | 30 | 2.977 | 0.009 | ns/op ByteBuffers.testHeapLoopGetShort | 16 | avgt | 30 | 5.296 | 0.014 | ns/op ByteBuffers.testHeapLoopGetShortRO | 16 | avgt | 30 | 5.301 | 0.01 | ns/op ByteBuffers.testHeapLoopGetShortSwap | 16 | avgt | 30 | 4.295 | 0.015 | ns/op ByteBuffers.testHeapLoopGetShortSwapRO | 16 | avgt | 30 | 5.305 | 0.019 | ns/op ByteBuffers.testHeapLoopPutByte | 16 | avgt | 30 | 4.517 | 0.027 | ns/op ByteBuffers.testHeapLoopPutByteSwap | 16 | avgt | 30 | 4.516 | 0.023 | ns/op ByteBuffers.testHeapLoopPutChar | 16 | avgt | 30 | 4.24 | 0.01 | ns/op ByteBuffers.testHeapLoopPutCharSwap | 16 | avgt | 30 | 4.229 | 0.008 | ns/op ByteBuffers.testHeapLoopPutDouble | 16 | avgt | 30 | 3.049 | 0.012 | ns/op ByteBuffers.testHeapLoopPutDoubleSwap | 16 | avgt | 30 | 2.989 | 0.009 | ns/op ByteBuffers.testHeapLoopPutFloat | 16 | avgt | 30 | 3.498 | 0.008 | ns/op ByteBuffers.testHeapLoopPutFloatSwap | 16 | avgt | 30 | 3.378 | 0.009 | ns/op ByteBuffers.testHeapLoopPutInt | 16 | avgt | 30 | 3.422 | 0.009 | ns/op ByteBuffers.testHeapLoopPutIntSwap | 16 | avgt | 30 | 3.405 | 0.007 | ns/op ByteBuffers.testHeapLoopPutLong | 16 | avgt | 30 | 3.025 | 0.006 | ns/op ByteBuffers.testHeapLoopPutLongSwap | 16 | avgt | 30 | 3.184 | 0.009 | ns/op ByteBuffers.testHeapLoopPutShort | 16 | avgt | 30 | 4.218 | 0.007 | ns/op ByteBuffers.testHeapLoopPutShortSwap | 16 | avgt | 30 | 4.215 | 0.007 | ns/op ByteBuffers.testDirectLoopGetByte | 1024 | avgt | 30 | 597.756 | 1.464 | ns/op ByteBuffers.testDirectLoopGetByteRO | 1024 | avgt | 30 | 599.101 | 1.923 | ns/op Baseline | ? | ? | ? | ? | ? | ? | ? | ? -- | -- | -- | -- | -- | -- | -- | -- | -- Improvement | ? | Benchmark | (size) | Mode | Cnt | Score | Error | Units 0.016 | ? | ByteBuffers.testDirectLoopGetByte | 16 | avgt | 30 | 4.533 | 0.031 | ns/op 0.037 | ? | ByteBuffers.testDirectLoopGetByteRO | 16 | avgt | 30 | 4.498 | 0.016 | ns/op 0.042 | ? | ByteBuffers.testDirectLoopGetByteSwap | 16 | avgt | 30 | 4.503 | 0.032 | ns/op 0.003 | ? | ByteBuffers.testDirectLoopGetByteSwapRO | 16 | avgt | 30 | 4.468 | 0.013 | ns/op 0.019 | ? | ByteBuffers.testDirectLoopGetChar | 16 | avgt | 30 | 4.474 | 0.045 | ns/op 0.014 | ? | ByteBuffers.testDirectLoopGetCharRO | 16 | avgt | 30 | 4.456 | 0.021 | ns/op 0.043 | ? | ByteBuffers.testDirectLoopGetCharSwap | 16 | avgt | 30 | 4.037 | 0.045 | ns/op 0.057 | ? | ByteBuffers.testDirectLoopGetCharSwapRO | 16 | avgt | 30 | 4.487 | 0.019 | ns/op 0.002 | ? | ByteBuffers.testDirectLoopGetDouble | 16 | avgt | 30 | 2.781 | 0.019 | ns/op 0.016 | ? | ByteBuffers.testDirectLoopGetDoubleRO | 16 | avgt | 30 | 2.772 | 0.018 | ns/op 0.014 | ? | ByteBuffers.testDirectLoopGetDoubleSwap | 16 | avgt | 30 | 2.776 | 0.015 | ns/op -0.028 | ? | ByteBuffers.testDirectLoopGetDoubleSwapRO | 16 | avgt | 30 | 2.755 | 0.005 | ns/op -0.036 | ? | ByteBuffers.testDirectLoopGetFloat | 16 | avgt | 30 | 3.201 | 0.017 | ns/op 0.037 | ? | ByteBuffers.testDirectLoopGetFloatRO | 16 | avgt | 30 | 3.261 | 0.048 | ns/op 0.063 | ? | ByteBuffers.testDirectLoopGetFloatSwap | 16 | avgt | 30 | 3.226 | 0.07 | ns/op 0.005 | ? | ByteBuffers.testDirectLoopGetFloatSwapRO | 16 | avgt | 30 | 3.245 | 0.037 | ns/op -0.001 | ? | ByteBuffers.testDirectLoopGetInt | 16 | avgt | 30 | 3.14 | 0.008 | ns/op 0.044 | ? | ByteBuffers.testDirectLoopGetIntRO | 16 | avgt | 30 | 3.172 | 0.024 | ns/op -0.008 | ? | ByteBuffers.testDirectLoopGetIntSwap | 16 | avgt | 30 | 3.158 | 0.012 | ns/op -0.076 | ? | ByteBuffers.testDirectLoopGetIntSwapRO | 16 | avgt | 30 | 3.138 | 0.007 | ns/op 0.028 | ? | ByteBuffers.testDirectLoopGetLong | 16 | avgt | 30 | 2.812 | 0.034 | ns/op 0.022 | ? | ByteBuffers.testDirectLoopGetLongRO | 16 | avgt | 30 | 2.8 | 0.04 | ns/op 0.022 | ? | ByteBuffers.testDirectLoopGetLongSwap | 16 | avgt | 30 | 2.81 | 0.044 | ns/op 0.012 | ? | ByteBuffers.testDirectLoopGetLongSwapRO | 16 | avgt | 30 | 2.783 | 0.027 | ns/op 0.053 | ? | ByteBuffers.testDirectLoopGetShort | 16 | avgt | 30 | 5.07 | 0.1 | ns/op 0.094 | ? | ByteBuffers.testDirectLoopGetShortRO | 16 | avgt | 30 | 5.076 | 0.065 | ns/op 0.051 | ? | ByteBuffers.testDirectLoopGetShortSwap | 16 | avgt | 30 | 4.061 | 0.041 | ns/op 0.115 | ? | ByteBuffers.testDirectLoopGetShortSwapRO | 16 | avgt | 30 | 5.132 | 0.198 | ns/op -0.016 | ? | ByteBuffers.testDirectLoopPutByte | 16 | avgt | 30 | 4.365 | 0.006 | ns/op -0.013 | ? | ByteBuffers.testDirectLoopPutByteSwap | 16 | avgt | 30 | 4.391 | 0.068 | ns/op 0.041 | ? | ByteBuffers.testDirectLoopPutChar | 16 | avgt | 30 | 4.022 | 0.112 | ns/op 0.111 | ? | ByteBuffers.testDirectLoopPutCharSwap | 16 | avgt | 30 | 4.062 | 0.236 | ns/op 0.001 | ? | ByteBuffers.testDirectLoopPutDouble | 16 | avgt | 30 | 2.799 | 0.017 | ns/op 0.19 | ? | ByteBuffers.testDirectLoopPutDoubleSwap | 16 | avgt | 30 | 3.006 | 0.308 | ns/op 0.146 | ? | ByteBuffers.testDirectLoopPutFloat | 16 | avgt | 30 | 3.273 | 0.008 | ns/op -0.054 | ? | ByteBuffers.testDirectLoopPutFloatSwap | 16 | avgt | 30 | 3.131 | 0.013 | ns/op -0.064 | ? | ByteBuffers.testDirectLoopPutInt | 16 | avgt | 30 | 3.169 | 0.004 | ns/op -0.045 | ? | ByteBuffers.testDirectLoopPutIntSwap | 16 | avgt | 30 | 3.137 | 0.004 | ns/op -0.026 | ? | ByteBuffers.testDirectLoopPutLong | 16 | avgt | 30 | 2.742 | 0.003 | ns/op -0.007 | ? | ByteBuffers.testDirectLoopPutLongSwap | 16 | avgt | 30 | 2.739 | 0.003 | ns/op -0.012 | ? | ByteBuffers.testDirectLoopPutShort | 16 | avgt | 30 | 3.969 | 0.004 | ns/op -0.019 | ? | ByteBuffers.testDirectLoopPutShortSwap | 16 | avgt | 30 | 3.94 | 0.007 | ns/op -0.048 | ? | ByteBuffers.testHeapBulkGetByte | 16 | avgt | 30 | 2.499 | 0.015 | ns/op -0.044 | ? | ByteBuffers.testHeapBulkPutByte | 16 | avgt | 30 | 2.488 | 0.003 | ns/op -0.039 | ? | ByteBuffers.testHeapLoopGetByte | 16 | avgt | 30 | 5.935 | 0.172 | ns/op -0.039 | ? | ByteBuffers.testHeapLoopGetByteRO | 16 | avgt | 30 | 5.967 | 0.215 | ns/op 0.017 | ? | ByteBuffers.testHeapLoopGetByteSwap | 16 | avgt | 30 | 5.895 | 0.027 | ns/op -0.043 | ? | ByteBuffers.testHeapLoopGetByteSwapRO | 16 | avgt | 30 | 6.043 | 0.136 | ns/op -0.127 | ? | ByteBuffers.testHeapLoopGetChar | 16 | avgt | 30 | 4.72 | 0.04 | ns/op 0.008 | ? | ByteBuffers.testHeapLoopGetCharRO | 16 | avgt | 30 | 4.737 | 0.032 | ns/op 0.001 | ? | ByteBuffers.testHeapLoopGetCharSwap | 16 | avgt | 30 | 4.205 | 0.02 | ns/op 0.082 | ? | ByteBuffers.testHeapLoopGetCharSwapRO | 16 | avgt | 30 | 4.759 | 0.036 | ns/op 0.01 | ? | ByteBuffers.testHeapLoopGetDouble | 16 | avgt | 30 | 2.981 | 0.012 | ns/op 0.015 | ? | ByteBuffers.testHeapLoopGetDoubleRO | 16 | avgt | 30 | 2.983 | 0.014 | ns/op 0.007 | ? | ByteBuffers.testHeapLoopGetDoubleSwap | 16 | avgt | 30 | 2.922 | 0.006 | ns/op 0.031 | ? | ByteBuffers.testHeapLoopGetDoubleSwapRO | 16 | avgt | 30 | 2.999 | 0.016 | ns/op 0.024 | ? | ByteBuffers.testHeapLoopGetFloat | 16 | avgt | 30 | 3.344 | 0.011 | ns/op 0.092 | ? | ByteBuffers.testHeapLoopGetFloatRO | 16 | avgt | 30 | 3.412 | 0.103 | ns/op 0.038 | ? | ByteBuffers.testHeapLoopGetFloatSwap | 16 | avgt | 30 | 3.355 | 0.024 | ns/op 0.018 | ? | ByteBuffers.testHeapLoopGetFloatSwapRO | 16 | avgt | 30 | 3.338 | 0.01 | ns/op 0.014 | ? | ByteBuffers.testHeapLoopGetInt | 16 | avgt | 30 | 3.329 | 0.007 | ns/op 0.013 | ? | ByteBuffers.testHeapLoopGetIntRO | 16 | avgt | 30 | 3.329 | 0.005 | ns/op 0.015 | ? | ByteBuffers.testHeapLoopGetIntSwap | 16 | avgt | 30 | 3.332 | 0.011 | ns/op 0.054 | ? | ByteBuffers.testHeapLoopGetIntSwapRO | 16 | avgt | 30 | 3.373 | 0.078 | ns/op 0.014 | ? | ByteBuffers.testHeapLoopGetLong | 16 | avgt | 30 | 2.941 | 0.01 | ns/op 0.057 | ? | ByteBuffers.testHeapLoopGetLongRO | 16 | avgt | 30 | 2.985 | 0.025 | ns/op 0.077 | ? | ByteBuffers.testHeapLoopGetLongSwap | 16 | avgt | 30 | 2.988 | 0.075 | ns/op -0.021 | ? | ByteBuffers.testHeapLoopGetLongSwapRO | 16 | avgt | 30 | 2.956 | 0.018 | ns/op -0.043 | ? | ByteBuffers.testHeapLoopGetShort | 16 | avgt | 30 | 5.253 | 0.043 | ns/op -0.085 | ? | ByteBuffers.testHeapLoopGetShortRO | 16 | avgt | 30 | 5.216 | 0.007 | ns/op 0.025 | ? | ByteBuffers.testHeapLoopGetShortSwap | 16 | avgt | 30 | 4.32 | 0.099 | ns/op 0.142 | ? | ByteBuffers.testHeapLoopGetShortSwapRO | 16 | avgt | 30 | 5.447 | 0.279 | ns/op 0.127 | ? | ByteBuffers.testHeapLoopPutByte | 16 | avgt | 30 | 4.644 | 0.116 | ns/op 0.199 | ? | ByteBuffers.testHeapLoopPutByteSwap | 16 | avgt | 30 | 4.715 | 0.148 | ns/op 0.221 | ? | ByteBuffers.testHeapLoopPutChar | 16 | avgt | 30 | 4.461 | 0.343 | ns/op -0.069 | ? | ByteBuffers.testHeapLoopPutCharSwap | 16 | avgt | 30 | 4.16 | 0.008 | ns/op -0.044 | ? | ByteBuffers.testHeapLoopPutDouble | 16 | avgt | 30 | 3.005 | 0.021 | ns/op -0.053 | ? | ByteBuffers.testHeapLoopPutDoubleSwap | 16 | avgt | 30 | 2.936 | 0.002 | ns/op -0.048 | ? | ByteBuffers.testHeapLoopPutFloat | 16 | avgt | 30 | 3.45 | 0.02 | ns/op -0.061 | ? | ByteBuffers.testHeapLoopPutFloatSwap | 16 | avgt | 30 | 3.317 | 0.003 | ns/op -0.054 | ? | ByteBuffers.testHeapLoopPutInt | 16 | avgt | 30 | 3.368 | 0.008 | ns/op -0.039 | ? | ByteBuffers.testHeapLoopPutIntSwap | 16 | avgt | 30 | 3.366 | 0.056 | ns/op -0.03 | ? | ByteBuffers.testHeapLoopPutLong | 16 | avgt | 30 | 2.995 | 0.019 | ns/op -0.051 | ? | ByteBuffers.testHeapLoopPutLongSwap | 16 | avgt | 30 | 3.133 | 0.013 | ns/op -0.034 | ? | ByteBuffers.testHeapLoopPutShort | 16 | avgt | 30 | 4.184 | 0.046 | ns/op -0.007 | ? | ByteBuffers.testHeapLoopPutShortSwap | 16 | avgt | 30 | 4.208 | 0.038 | ns/op ------------- PR: https://git.openjdk.org/jdk/pull/11755 From rriggs at openjdk.org Thu Dec 22 17:37:48 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 22 Dec 2022 17:37:48 GMT Subject: RFR: 8299193: Declare Buffer.capacity final In-Reply-To: References: Message-ID: <87NgK2D-DqfYj9aqH31dBpxVM6B8kiZsdD_5_UWjnHU=.a05215ed-1e35-4c6d-adf1-6db35e244ff6@github.com> On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final` as the value never changes outside the constructors. The contribution of capacity being final is minimal in the perf results, being only used as the limit in the for-loops. Regardless, the field should be final. Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11755 From dholmes at openjdk.org Fri Dec 23 03:57:51 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Dec 2022 03:57:51 GMT Subject: RFR: 8299193: Declare Buffer.capacity final In-Reply-To: References: Message-ID: <9v1oJB8rHf-vAyk_M10BWKqsJPPcy2rLy8q-y11vboU=.4f0a4159-d71a-4677-a179-b8b305353581@github.com> On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final` as the value never changes outside the constructors. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11755 From jpai at openjdk.org Fri Dec 23 06:27:48 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Dec 2022 06:27:48 GMT Subject: RFR: 8299193: Declare Buffer.capacity final In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 12:22:33 GMT, Per Minborg wrote: > It is possible to declare the field `capacity` in `java.nio.Buffer` `final` as the value never changes outside the constructors. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11755 From jpai at openjdk.org Fri Dec 23 06:31:48 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 23 Dec 2022 06:31:48 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 09:29:59 GMT, Per Minborg wrote: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. Hello Per, making the field `final` looks fine to me. Please update the copyright year on this file before integrating. Please also add a `noreg-trivial` label to the JBS issue. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11752 From mernst at openjdk.org Tue Dec 27 14:26:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge ../jdk-openjdk into typos-typos - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02 Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Tue Dec 27 14:26:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai wrote: >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > > I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs. Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes. I have pulled master and resolved merge conflicts. Only 11 typo fixes remain. Could someone shepherd those into the codebase? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From duke at openjdk.org Thu Dec 29 12:57:49 2022 From: duke at openjdk.org (altrisi) Date: Thu, 29 Dec 2022 12:57:49 GMT Subject: RFR: 8299187: Ensure safe publication of name in ByteOrder In-Reply-To: References: Message-ID: <1tsg0cwDeeDmGO19qdIzZ5w5bJC7x7ySMtirXgVbK0c=.5a0f9a62-fe82-4376-b862-5e3de1c4a8cf@github.com> On Wed, 21 Dec 2022 09:29:59 GMT, Per Minborg wrote: > This PR proposes to declare the field `ByteOrder.name` `final`. > > This will ensure the class is thread safe and is using safe publication. Is there any reason why it doesn't just use the enum name? ------------- PR: https://git.openjdk.org/jdk/pull/11752