From mcimadamore at openjdk.java.net Thu Jul 1 00:08:03 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Jul 2021 00:08:03 GMT Subject: RFR: 8269700: source level for IntelliJ JDK project is set incorrectly In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 11:43:38 GMT, Sergei Ustimenko wrote: > After generating an Intellij project with the `idea.sh` script, IDEA might get confused > with the language level settings in generated .idea/misc.xml. This results in a problem > with modules discussed in https://mail.openjdk.java.net/pipermail/ide-support-dev/2021-June/000082.html. > To mitigate the problem changing the project's language level helps. > > This patch sets language level for jdk Intellij Project to [X (Experimental Features)](https://github.com/JetBrains/intellij-community/blob/master/jps/model-api/src/org/jetbrains/jps/model/java/LanguageLevel.java) to avoid such problems. > > As a side effect following term needs to be accepted in IDEA once opening the project for the first time: > > You must accept the terms of legal notice of the beta Java specification > to enable support for "X - Experimental features". The implementation > of an early-draft specification developed under the Java Community Process (JCP) > is made available for testing and evaluation purposes only and is not > compatible with any specification of the JCP. The change looks good to me! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4634 From doko at ubuntu.com Thu Jul 1 11:28:26 2021 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 1 Jul 2021 13:28:26 +0200 Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: References: Message-ID: <5d2a2fb4-0047-c521-9c27-6a70b30d8738@ubuntu.com> On 6/2/21 6:25 PM, Jonathan Gibbons wrote: > Please review the change to update to using jtreg 6. > > The primary change is to the jib-profiles.js file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > All the tests that could be updated ahead of time have been updated. There are a few tests remaining that need to be done at this time, because of the change in the module name for TestNG 7.3. It changed from a default of `testng` to and explicit `org.testng`. > > ------------- > > Commit messages: > - JDK-8266254: Update to use jtreg 6 > > Changes: https://git.openjdk.java.net/jdk/pull/4315/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4315&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8266254 > Stats: 17 lines in 11 files changed: 0 ins; 1 del; 16 mod > Patch: https://git.openjdk.java.net/jdk/pull/4315.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/4315/head:pull/4315 > > PR: https://git.openjdk.java.net/jdk/pull/4315 what's the status of this? Trying to run the tests for 17+29 using jtreg 6+1, I get: + jtreg -conc:auto -verbose:summary -automatic -retain:none -ignore:quiet -agentvm -timeout:5 -workDir:/tmp//hotspot/JTwork -reportDir:jtreg-test-output//hotspot//0/JTreport -jdk:build/bootcycle-build/images/jdk -exclude:test/hotspot/jtreg/ProblemList.txt -dir:test/hotspot/jtreg :hotspot_compiler :hotspot_gc :hotspot_runtime :hotspot_serviceability Error: Unexpected exception occurred! java.lang.NumberFormatException: For input string: "6+1" java.lang.NumberFormatException: For input string: "6+1" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67) at java.base/java.lang.Integer.parseInt(Integer.java:668) at java.base/java.lang.Integer.parseInt(Integer.java:786) at com.sun.javatest.regtest.tool.Version.parseDottedInts(Version.java:166) at com.sun.javatest.regtest.tool.Version.compareTo(Version.java:185) at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1131) at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1079) at com.sun.javatest.regtest.tool.Tool.main(Tool.java:148) at com.sun.javatest.regtest.Main.main(Main.java:58) + exit_code=6 Matthias From shade at redhat.com Thu Jul 1 11:41:18 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Jul 2021 13:41:18 +0200 Subject: RFR: JDK-8266254: Update to use jtreg 6 In-Reply-To: <5d2a2fb4-0047-c521-9c27-6a70b30d8738@ubuntu.com> References: <5d2a2fb4-0047-c521-9c27-6a70b30d8738@ubuntu.com> Message-ID: <3795b2a6-7483-eddf-b953-5d0db12b5162@redhat.com> Hi Matthias, On 7/1/21 1:28 PM, Matthias Klose wrote: > what's the status of this? Trying to run the tests for 17+29 using jtreg 6+1, I > get: I saw a similar problem with some custom jtreg builds. IIRC, that happens when jtreg6 source is built with "old" make/build-all.sh, not with the new "make/build.sh". I know this version works for me with current jdk17 and jdk: https://builds.shipilev.net/jtreg/jtreg-6+1.zip -- Thanks, -Aleksey From jvernee at openjdk.java.net Thu Jul 1 14:49:10 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 1 Jul 2021 14:49:10 GMT Subject: RFR: 8269758: idea.sh doesn't work when there are multiple configurations available. Message-ID: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> >From the JBS issue: The idea.sh script invokes `make`, but doesn't specify a configuration. So, when multiple configurations are present, this results in an error like this: $ bash bin/idea.sh java.base Error: No CONF given, but more than one configuration found. Available configurations in /mnt/c/jdk/build: * conf1 * conf2 * conf3 Please retry building with CONF= (or SPEC=). ------------- Commit messages: - Allow specifying conf to idea.sh Changes: https://git.openjdk.java.net/jdk/pull/4654/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269758 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4654/head:pull/4654 PR: https://git.openjdk.java.net/jdk/pull/4654 From jvernee at openjdk.java.net Thu Jul 1 15:02:12 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 1 Jul 2021 15:02:12 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly Message-ID: >From the JBS issue: Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4654 Commit messages: - use CYGPATH variable instead of calling cygpath directly Changes: https://git.openjdk.java.net/jdk/pull/4655/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4655&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269760 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4655/head:pull/4655 PR: https://git.openjdk.java.net/jdk/pull/4655 From jvernee at openjdk.java.net Thu Jul 1 15:10:22 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 1 Jul 2021 15:10:22 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL Message-ID: >From the JBS issue: At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/4655 Commit messages: - Add .exe suffix when invoking javac on WSL Changes: https://git.openjdk.java.net/jdk/pull/4656/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269761 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4656/head:pull/4656 PR: https://git.openjdk.java.net/jdk/pull/4656 From mcimadamore at openjdk.java.net Thu Jul 1 16:09:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Jul 2021 16:09:04 GMT Subject: RFR: 8269758: idea.sh doesn't work when there are multiple configurations available. In-Reply-To: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> References: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> Message-ID: On Thu, 1 Jul 2021 14:41:53 GMT, Jorn Vernee wrote: > From the JBS issue: > > The idea.sh script invokes `make`, but doesn't specify a configuration. So, when multiple configurations are present, this results in an error like this: > > > $ bash bin/idea.sh java.base > Error: No CONF given, but more than one configuration found. > Available configurations in /mnt/c/jdk/build: > * conf1 > * conf2 > * conf3 > Please retry building with CONF= (or SPEC=). Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4654 From mcimadamore at openjdk.java.net Thu Jul 1 16:10:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Jul 2021 16:10:10 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 14:54:04 GMT, Jorn Vernee wrote: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. > > Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. Not an expert on the value of these variables, but the changes you have look consistent. ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4655 From mcimadamore at openjdk.java.net Thu Jul 1 16:12:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 1 Jul 2021 16:12:58 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 15:02:03 GMT, Jorn Vernee wrote: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. Nice! Thanks. Question though: with WSL, the boot JDK could also be a Linux JDK, no? If that's the case, then the .exe suffix would be bad? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4656 From jvernee at openjdk.java.net Thu Jul 1 16:22:06 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 1 Jul 2021 16:22:06 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 16:06:47 GMT, Maurizio Cimadamore wrote: > Not an expert on the value of these variables My own line of thought is that it is reasonable to expect that anything found in the `CYGPATH` variable is fine to treat as if it were `cygpath` like this (this could be an alternative `cygpath` binary, or a substitutable implementation like `wslpath`) ------------- PR: https://git.openjdk.java.net/jdk/pull/4655 From erikj at openjdk.java.net Fri Jul 2 14:15:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Jul 2021 14:15:51 GMT Subject: RFR: 8269758: idea.sh doesn't work when there are multiple configurations available. In-Reply-To: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> References: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> Message-ID: On Thu, 1 Jul 2021 14:41:53 GMT, Jorn Vernee wrote: > From the JBS issue: > > The idea.sh script invokes `make`, but doesn't specify a configuration. So, when multiple configurations are present, this results in an error like this: > > > $ bash bin/idea.sh java.base > Error: No CONF given, but more than one configuration found. > Available configurations in /mnt/c/jdk/build: > * conf1 > * conf2 > * conf3 > Please retry building with CONF= (or SPEC=). Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4654 From erikj at openjdk.java.net Fri Jul 2 14:18:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Jul 2021 14:18:07 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 16:10:03 GMT, Maurizio Cimadamore wrote: > Question though: with WSL, the boot JDK could also be a Linux JDK, no? If that's the case, then the .exe suffix would be bad? That's a good point, maybe check if BOOT_JDK/bin/java.exe exists and have that as the condition? ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From erikj at openjdk.java.net Fri Jul 2 14:19:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 2 Jul 2021 14:19:06 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 14:54:04 GMT, Jorn Vernee wrote: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. > > Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4655 From ddong at openjdk.java.net Fri Jul 2 15:33:18 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 2 Jul 2021 15:33:18 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain Message-ID: Hi, Could I have a review of this improvement that eliminates 'is_large' if the event size range is certain? JDK-8246260 introduced event large checks to reduce the recording size. This check could be eliminated at compile/build time when one of the following conditions is satisfied: 1. if the max size is < 128 2. if the min size is >= 128 The max size and the min size could be computed for the most native events at the generation phase. And I think this improvement may also be done for JDK events. ------------- Commit messages: - format - trivial update - init Changes: https://git.openjdk.java.net/jdk/pull/4670/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269823 Stats: 169 lines in 5 files changed: 142 ins; 9 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/4670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4670/head:pull/4670 PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Fri Jul 2 15:37:52 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Fri, 2 Jul 2021 15:37:52 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain In-Reply-To: References: Message-ID: On Fri, 2 Jul 2021 15:20:50 GMT, Denghui Dong wrote: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. I think some other improvements could be done based on the max/min event size, e.g. merge `ensure_size` operations ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Sat Jul 3 00:46:13 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sat, 3 Jul 2021 00:46:13 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4670/files - new: https://git.openjdk.java.net/jdk/pull/4670/files/89d2710e..d30f1b6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=00-01 Stats: 37 lines in 2 files changed: 26 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/4670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4670/head:pull/4670 PR: https://git.openjdk.java.net/jdk/pull/4670 From egahlin at openjdk.java.net Sat Jul 3 11:35:51 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 3 Jul 2021 11:35:51 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 00:46:13 GMT, Denghui Dong wrote: >> Hi, >> >> Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? >> >> JDK-8246260 introduced event large checks to reduce the recording size. >> This check could be eliminated at compile/build time when one of the following conditions is satisfied: >> 1. if the max size is < 128 >> 2. if the min size is >= 128 >> >> The max size and the min size could be computed for the most native events at the generation phase. >> >> And I think this improvement may also be done for JDK events. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > refactor This complicates the implementation with what I would assume negligible impact on performance. Do you have measurements that proves that throughput is improved significantly with this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Sun Jul 4 08:36:03 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Sun, 4 Jul 2021 08:36:03 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v2] In-Reply-To: References: Message-ID: On Sat, 3 Jul 2021 00:46:13 GMT, Denghui Dong wrote: >> Hi, >> >> Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? >> >> JDK-8246260 introduced event large checks to reduce the recording size. >> This check could be eliminated at compile/build time when one of the following conditions is satisfied: >> 1. if the max size is < 128 >> 2. if the min size is >= 128 >> >> The max size and the min size could be computed for the most native events at the generation phase. >> >> And I think this improvement may also be done for JDK events. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > refactor Hi Erik, Thanks for the comments. I only measure it on a marco benchmark that sends 100 same jfr native events which contain a uint field. with this patch: Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.testEmit thrpt 20 8251457.275 2707.578 ops/s without this patch: Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.testEmit thrpt 20 6608780.910 5604.914 ops/s I agree with you that this optimization may not affect the overall performance of the application. I think we can do further optimization based on this. For example, in the current implementation, we need to check whether there are enough buffers before writing each field of the event. If the available buffer is greater than the max size of an event, then we only need to check it once. In addition, other current properties, such as hasThrottle, hasStackTrace, are pre-checked at compile time. Therefore, in my opinion, this optimization is necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From github.com+5709644+fdesu at openjdk.java.net Mon Jul 5 08:40:52 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Mon, 5 Jul 2021 08:40:52 GMT Subject: RFR: 8269700: source level for IntelliJ JDK project is set incorrectly In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 11:43:38 GMT, Sergei Ustimenko wrote: > After generating an Intellij project with the `idea.sh` script, IDEA might get confused > with the language level settings in generated .idea/misc.xml. This results in a problem > with modules discussed in https://mail.openjdk.java.net/pipermail/ide-support-dev/2021-June/000082.html. > To mitigate the problem changing the project's language level helps. > > This patch sets language level for jdk Intellij Project to [X (Experimental Features)](https://github.com/JetBrains/intellij-community/blob/master/jps/model-api/src/org/jetbrains/jps/model/java/LanguageLevel.java) to avoid such problems. > > As a side effect following term needs to be accepted in IDEA once opening the project for the first time: > > You must accept the terms of legal notice of the beta Java specification > to enable support for "X - Experimental features". The implementation > of an early-draft specification developed under the Java Community Process (JCP) > is made available for testing and evaluation purposes only and is not > compatible with any specification of the JCP. I would really appreciate and it would be absolutely awesome if someone could sponsor this change or let me know if it needs some more polishing. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/4634 From github.com+5709644+fdesu at openjdk.java.net Mon Jul 5 09:12:52 2021 From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko) Date: Mon, 5 Jul 2021 09:12:52 GMT Subject: Integrated: 8269700: source level for IntelliJ JDK project is set incorrectly In-Reply-To: References: Message-ID: On Wed, 30 Jun 2021 11:43:38 GMT, Sergei Ustimenko wrote: > After generating an Intellij project with the `idea.sh` script, IDEA might get confused > with the language level settings in generated .idea/misc.xml. This results in a problem > with modules discussed in https://mail.openjdk.java.net/pipermail/ide-support-dev/2021-June/000082.html. > To mitigate the problem changing the project's language level helps. > > This patch sets language level for jdk Intellij Project to [X (Experimental Features)](https://github.com/JetBrains/intellij-community/blob/master/jps/model-api/src/org/jetbrains/jps/model/java/LanguageLevel.java) to avoid such problems. > > As a side effect following term needs to be accepted in IDEA once opening the project for the first time: > > You must accept the terms of legal notice of the beta Java specification > to enable support for "X - Experimental features". The implementation > of an early-draft specification developed under the Java Community Process (JCP) > is made available for testing and evaluation purposes only and is not > compatible with any specification of the JCP. This pull request has now been integrated. Changeset: 371d996a Author: Sergei Ustimenko Committer: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/371d996a892fc6fbf82110a1ca5b3d64a801b6fc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8269700: source level for IntelliJ JDK project is set incorrectly Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/4634 From github.com+85193727+jtfuller111 at openjdk.java.net Mon Jul 5 10:02:53 2021 From: github.com+85193727+jtfuller111 at openjdk.java.net (jtfuller111) Date: Mon, 5 Jul 2021 10:02:53 GMT Subject: Integrated: JDK-8263389 IGV: Zooming changes the point that is currently centered In-Reply-To: References: Message-ID: <238br7sEnbgF29N0zgvoGUYqRxezS3PmEm6RQeW8hOM=.ad7ffb88-d775-4fe6-82d8-f2297cbb5bbf@github.com> On Tue, 1 Jun 2021 20:00:07 GMT, jtfuller111 wrote: > Fixing the zoom issue on IGV. I tested this on Windows and Linux and zooming now works as expected. This pull request has now been integrated. Changeset: 164eff8c Author: James Fuller Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/164eff8c8a8f96efc5bfb659d8b02de420b8416b Stats: 17 lines in 1 file changed: 9 ins; 6 del; 2 mod 8263389: IGV: Zooming changes the point that is currently centered Reviewed-by: rrich, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/4291 From jvernee at openjdk.java.net Mon Jul 5 10:20:53 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:20:53 GMT Subject: Integrated: 8269758: idea.sh doesn't work when there are multiple configurations available. In-Reply-To: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> References: <685DeZ2z-zd4XjPU_eDeBLtT35ZhQ8hp0-b7uhEXOa0=.ad312af0-52b4-42a8-b10a-c09b187f5efb@github.com> Message-ID: On Thu, 1 Jul 2021 14:41:53 GMT, Jorn Vernee wrote: > From the JBS issue: > > The idea.sh script invokes `make`, but doesn't specify a configuration. So, when multiple configurations are present, this results in an error like this: > > > $ bash bin/idea.sh java.base > Error: No CONF given, but more than one configuration found. > Available configurations in /mnt/c/jdk/build: > * conf1 > * conf2 > * conf3 > Please retry building with CONF= (or SPEC=). This pull request has now been integrated. Changeset: 73198968 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/73198968e245362607a8b2e4f80e261fc77d0441 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8269758: idea.sh doesn't work when there are multiple configurations available. Reviewed-by: mcimadamore, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4654 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Mon Jul 5 10:28:15 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Mon, 5 Jul 2021 10:28:15 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly In-Reply-To: References: Message-ID: <0CQ9wm59lhXRqrMqZXe2VbVRAxWgiGjw1SmYZPiNo2E=.b1446413-765f-4d34-812f-9c77f7112e28@github.com> On Thu, 1 Jul 2021 14:54:04 GMT, Jorn Vernee wrote: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. > > Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout Idea_Conf git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4655 From jvernee at openjdk.java.net Mon Jul 5 10:28:15 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:28:15 GMT Subject: RFR: 8269760: idea.sh should not invoke cygpath directly [v2] In-Reply-To: References: Message-ID: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. > > Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. Jorn Vernee 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4655/files - new: https://git.openjdk.java.net/jdk/pull/4655/files/a95d4154..a95d4154 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4655&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4655&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4655.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4655/head:pull/4655 PR: https://git.openjdk.java.net/jdk/pull/4655 From jvernee at openjdk.java.net Mon Jul 5 10:28:16 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:28:16 GMT Subject: Integrated: 8269760: idea.sh should not invoke cygpath directly In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 14:54:04 GMT, Jorn Vernee wrote: > From the JBS issue: > > Currently idea.sh checks if `CYGPATH` is set, and then continues by invoking `cygpath` directly. > > This doesn't work if `CYGPATH` is not actually set to `cygpath`, but to something else, such as `wslpath`. > > Instead of invoking `cygpath` directly, the value of the `CYGPATH` variable should be used. This pull request has now been integrated. Changeset: 76783cd8 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/76783cd8cbb390dc9ac1da72962ce15e98ea5d3c Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod 8269760: idea.sh should not invoke cygpath directly Reviewed-by: mcimadamore, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4655 From jvernee at openjdk.java.net Mon Jul 5 10:31:13 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:31:13 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v2] In-Reply-To: References: Message-ID: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. Jorn Vernee 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4656/files - new: https://git.openjdk.java.net/jdk/pull/4656/files/9b0f6ba5..9b0f6ba5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4656/head:pull/4656 PR: https://git.openjdk.java.net/jdk/pull/4656 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Mon Jul 5 10:31:13 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Mon, 5 Jul 2021 10:31:13 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 15:02:03 GMT, Jorn Vernee wrote: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout Idea_Cygpath git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From jvernee at openjdk.java.net Mon Jul 5 10:40:17 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:40:17 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 10:31:13 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory >> >> Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. > > Jorn Vernee 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. I realized this as well, but it doesn't look like the script works when using a linux boot JDK any way currently. The source file that is passed to `javac` is a Windows path: JAVAC_SOURCE_FILE=`$CYGPATH -am $IDEA_OUTPUT/src/idea/IdeaLoggerWrapper.java` ... $BOOT_JDK/bin/$JAVAC$EXE_SUFFIX -d $JAVAC_CLASSES -sourcepath $JAVAC_SOURCE_PATH -cp $JAVAC_CP $JAVAC_SOURCE_FILE So, I could change the test to look for `BOOT_JDK/bin/java.exe`, but then the script fails with: error: file not found: H:/openjdk/git-jdk2/.idea/src/idea/IdeaLoggerWrapper.java The rest of the script checks for `"x$WSL_DISTRO_NAME" != "x"` and then uses Windows style paths. So, I'd rather leave the current check for adding the `.exe` suffix to do the same (consistent with the rest of the script), and leave adding support for running the script with a linux boot JDK on WSL for another time, since that doesn't seem to be a quick fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From jvernee at openjdk.java.net Mon Jul 5 10:40:15 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 10:40:15 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v3] In-Reply-To: References: Message-ID: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into Idea_Exe - Add .exe suffix when invoking javac on WSL - use CYGPATH variable instead of calling cygpath directly - Allow specifying conf to idea.sh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4656/files - new: https://git.openjdk.java.net/jdk/pull/4656/files/9b0f6ba5..cd925bbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=01-02 Stats: 2704 lines in 99 files changed: 1617 ins; 450 del; 637 mod Patch: https://git.openjdk.java.net/jdk/pull/4656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4656/head:pull/4656 PR: https://git.openjdk.java.net/jdk/pull/4656 From jvernee at openjdk.java.net Mon Jul 5 11:00:54 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 11:00:54 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v3] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 10:40:15 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory >> >> Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into Idea_Exe > - Add .exe suffix when invoking javac on WSL > - use CYGPATH variable instead of calling cygpath directly > - Allow specifying conf to idea.sh Hmm, now that I'm looking again, I see that an earlier block also tries to set `JAVAC` to `javac.exe` on WSL, but it never gets executed because `CYGPATH` is set in my environment: if [ "x$CYGPATH" != "x" ] ; then ## CYGPATH may be set in env.cfg ... JAVAC=javac elif [ "x$WSL_DISTRO_NAME" != "x" ]; then ... JAVAC=javac.exe else Of course, when I remove my fix, and move the `"x$WSL_DISTRO_NAME" != "x"` to the front, this also fails on a linux boot JDK because `javac.exe` doesn't exist. If I remove the `.exe` suffix then the usage of `realpath` in that same block makes the script work on a linux boot JDK, but fails again on a Windows boot JDK because of the missing .exe suffix. I'll try to see if I can make the existing logic work on both JDK types ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From ihse at openjdk.java.net Mon Jul 5 13:18:02 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 5 Jul 2021 13:18:02 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions Message-ID: GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. ------------- Commit messages: - Update to msdev 14.29 for Windows/aarch64. - Revert "8268861: Disable Windows-Aarch64 build in GitHub Actions" Changes: https://git.openjdk.java.net/jdk/pull/4681/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4681&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268860 Stats: 92 lines in 1 file changed: 91 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4681/head:pull/4681 PR: https://git.openjdk.java.net/jdk/pull/4681 From jvernee at openjdk.java.net Mon Jul 5 18:05:19 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 5 Jul 2021 18:05:19 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4] In-Reply-To: References: Message-ID: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Make idea.sh work on WSL with a Linux boot JDK ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4656/files - new: https://git.openjdk.java.net/jdk/pull/4656/files/cd925bbf..90909fda Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4656&range=02-03 Stats: 26 lines in 1 file changed: 12 ins; 7 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/4656.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4656/head:pull/4656 PR: https://git.openjdk.java.net/jdk/pull/4656 From mcimadamore at openjdk.java.net Mon Jul 5 20:13:52 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 5 Jul 2021 20:13:52 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4] In-Reply-To: References: Message-ID: <5OujURN2_v0x8u0hecZYgv000-WKK4oJ3Z4PxZOQ7UY=.afc5bd5f-e5c2-45c3-8384-acf87325b5a0@github.com> On Mon, 5 Jul 2021 18:05:19 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory >> >> Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make idea.sh work on WSL with a Linux boot JDK Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4656 From dholmes at openjdk.java.net Mon Jul 5 21:10:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Jul 2021 21:10:55 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: References: Message-ID: <5G_ghUe-V5tGetvmNVLsjo9cBMkP5ksC0PUHMG-Z32M=.caf040e9-22fd-4596-b4e8-4d7fe7d98c6a@github.com> On Mon, 5 Jul 2021 13:10:36 GMT, Magnus Ihse Bursie wrote: > GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) > > Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. > > This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. Hi Magnus, I think we need to understand more about why this stopped working before reenabling it. I also would like to know how this fixes things when according to the Github folk: https://github.com/actions/virtual-environments/issues/3567#issuecomment-862908135 the issue is using VC instead of cygwin. If there is a misunderstanding about how the build works it would be good to clear that up and document it. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/4681 From ihse at openjdk.java.net Mon Jul 5 21:31:58 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 5 Jul 2021 21:31:58 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:10:36 GMT, Magnus Ihse Bursie wrote: > GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) > > Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. > > This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. There were a bit of initial confusion in the actions bug you mention, but in the end that was also what supplied the solution. The quote about "VC instead of cygwin" is just confused and misleading; we are using VC (that is, Visual Studio) as well as Cygwin. When @dsame played around in his personal fork, he never changed any of these. But it piqued my interest when he said he got it building, so I had a closer look at what he actually did. There were some irrelevant changes, but the core fix was to remove the `--with-msvc-toolset-version` argument. This forced configure to pick up the standard installed version of msdev, and that one was correctly configured to build. However, this is not a solution that we would like to have, since we want more control of what version is used to build. The price we pay for that, is to occasionally having to bump the version like this, when stuff starts to break. (We recently have to fix ubuntu builds when our selected compiler were removed from the apt sources.) So I changed this to explicitly set the version of msdev that worked. I don't think we will ever find out what changed with the GHA environment. We are never going to have that kind of control over it. So we will just have to go with the flow, and patch submit.yml whenever we ran across new snags. And the misunderstanding about how the build works resides purely in the Github action team. The documentation is clear enough, but I don't expect them to get any more knowledge about our building system. ------------- PR: https://git.openjdk.java.net/jdk/pull/4681 From dholmes at openjdk.java.net Mon Jul 5 21:49:53 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Jul 2021 21:49:53 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: References: Message-ID: <98J3oNKgWXFkB4_eI2q3LISBi0zdz4TePR1bjtz5pUQ=.f3619da8-ff92-4e78-9301-5c0b2be7a009@github.com> On Mon, 5 Jul 2021 13:10:36 GMT, Magnus Ihse Bursie wrote: > GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) > > Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. > > This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. Thanks for the explanation and for updating the github issue! It is still unsettling that we don't know what changed as no-one has responsibility for keeping this part working, and it will rely on concerned volunteers to monitor and update. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4681 From ihse at openjdk.java.net Tue Jul 6 00:32:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 6 Jul 2021 00:32:53 GMT Subject: Integrated: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:10:36 GMT, Magnus Ihse Bursie wrote: > GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) > > Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. > > This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. This pull request has now been integrated. Changeset: acc3d995 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/acc3d995355b646c581623b0df5facbcdbfa4721 Stats: 92 lines in 1 file changed: 91 ins; 0 del; 1 mod 8268860: Windows-Aarch64 build is failing in GitHub actions Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/4681 From ihse at openjdk.java.net Tue Jul 6 00:32:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 6 Jul 2021 00:32:52 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 13:10:36 GMT, Magnus Ihse Bursie wrote: > GHA for Windows/aarch64 was disabled in [JDK-8268861](https://bugs.openjdk.java.net/browse/JDK-8268861). The problem with GHA for windows/aarch64 was due to using Visual Studio 14.28. (Why this suddenly *started* failing is a mystery for another time. Perhaps GitHub, or Microsoft, changed something...) > > Upgrading to 14.29 (which is the default on the GitHub actions machines) solves the problem. > > This patch contains a revert of JDK-8268861, followed by an upgrade to 14.29. Thanks for the review! I agree that the GHA situation is far from ideal. (But we've been through this discussion before...) ------------- PR: https://git.openjdk.java.net/jdk/pull/4681 From ddong at openjdk.java.net Tue Jul 6 06:06:13 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 6 Jul 2021 06:06:13 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4670/files - new: https://git.openjdk.java.net/jdk/pull/4670/files/d30f1b6a..fa8c16cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=01-02 Stats: 19 lines in 3 files changed: 0 ins; 9 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/4670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4670/head:pull/4670 PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Tue Jul 6 06:19:07 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Tue, 6 Jul 2021 06:19:07 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v4] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. Denghui Dong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4670/files - new: https://git.openjdk.java.net/jdk/pull/4670/files/fa8c16cb..e8fdcb54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=02-03 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4670/head:pull/4670 PR: https://git.openjdk.java.net/jdk/pull/4670 From jvernee at openjdk.java.net Tue Jul 6 10:41:49 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 6 Jul 2021 10:41:49 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4] In-Reply-To: References: Message-ID: On Mon, 5 Jul 2021 18:05:19 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory >> >> Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make idea.sh work on WSL with a Linux boot JDK bin/idea.sh line 74: > 72: if [ -e $IDEA_OUTPUT ] ; then > 73: rm -r $IDEA_OUTPUT > 74: fi Was getting some weird errors when the `.idea` folder already existed when running the script, so I added this. It seems useful, so I've left it in. ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From mcimadamore at openjdk.java.net Tue Jul 6 10:48:51 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 6 Jul 2021 10:48:51 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 10:38:35 GMT, Jorn Vernee wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Make idea.sh work on WSL with a Linux boot JDK > > bin/idea.sh line 74: > >> 72: if [ -e $IDEA_OUTPUT ] ; then >> 73: rm -r $IDEA_OUTPUT >> 74: fi > > Was getting some weird errors when the `.idea` folder already existed when running the script, so I added this. It seems useful, so I've left it in. Yep - noticed that, it's good ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From erikj at openjdk.java.net Tue Jul 6 21:09:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 6 Jul 2021 21:09:48 GMT Subject: RFR: 8269761: idea.sh missing .exe suffix when invoking javac on WSL [v4] In-Reply-To: References: Message-ID: <9zsBR9BLVxDf3hl4QVxjEZVi3HnL43Unc-2Jd8bZLgQ=.d1f37fce-4b88-484b-a99f-1ece47840aa5@github.com> On Mon, 5 Jul 2021 18:05:19 GMT, Jorn Vernee wrote: >> From the JBS issue: >> >> At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: >> >> bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory >> >> Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Make idea.sh work on WSL with a Linux boot JDK Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From jlahoda at openjdk.java.net Wed Jul 7 07:37:20 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 07:37:20 GMT Subject: [jdk17] RFR: 8266036: class file for sun.misc.Contended not found [v3] In-Reply-To: References: Message-ID: > [this is an improved version of openjdk/jdk PR: > https://github.com/openjdk/jdk/pull/4428 > ] > > The ct.sym may contain classfiles referring to annotations that are not present in ct.sym (liek JDK's internal annotation sun.misc.Contended). If javac will try to load them (while discovering annotations for the purpose of detecting which annotation processors should be run), an error will be produced (please see the issue). The proposal is to strip annotations that are not present in ct.sym when generating ct.sym. > > As noted by @jddarcy, we also need a special handling of ValueBased, which this patch should do, so it also solves https://bugs.openjdk.java.net/browse/JDK-8258421 Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Fixing typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/27/files - new: https://git.openjdk.java.net/jdk17/pull/27/files/187ad580..ed26b697 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=27&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/27.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/27/head:pull/27 PR: https://git.openjdk.java.net/jdk17/pull/27 From jlahoda at openjdk.java.net Wed Jul 7 09:52:59 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Wed, 7 Jul 2021 09:52:59 GMT Subject: [jdk17] Integrated: 8266036: class file for sun.misc.Contended not found In-Reply-To: References: Message-ID: On Fri, 11 Jun 2021 13:09:55 GMT, Jan Lahoda wrote: > [this is an improved version of openjdk/jdk PR: > https://github.com/openjdk/jdk/pull/4428 > ] > > The ct.sym may contain classfiles referring to annotations that are not present in ct.sym (liek JDK's internal annotation sun.misc.Contended). If javac will try to load them (while discovering annotations for the purpose of detecting which annotation processors should be run), an error will be produced (please see the issue). The proposal is to strip annotations that are not present in ct.sym when generating ct.sym. > > As noted by @jddarcy, we also need a special handling of ValueBased, which this patch should do, so it also solves https://bugs.openjdk.java.net/browse/JDK-8258421 This pull request has now been integrated. Changeset: 7fcd5ca0 Author: Jan Lahoda URL: https://git.openjdk.java.net/jdk17/commit/7fcd5ca0258b1dc6c34c98ced177ee4dc7945f26 Stats: 325 lines in 15 files changed: 215 ins; 16 del; 94 mod 8266036: class file for sun.misc.Contended not found 8258421: (jdeprscan) tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java failed with "error: cannot access jdk.internal.ValueBased" Reviewed-by: darcy ------------- PR: https://git.openjdk.java.net/jdk17/pull/27 From jvernee at openjdk.java.net Wed Jul 7 10:07:56 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 7 Jul 2021 10:07:56 GMT Subject: Integrated: 8269761: idea.sh missing .exe suffix when invoking javac on WSL In-Reply-To: References: Message-ID: On Thu, 1 Jul 2021 15:02:03 GMT, Jorn Vernee wrote: > From the JBS issue: > > At the end, idea.sh tries to invoke javac, but when running on WSL this results in the following error: > > bin/idea.sh: line 249: /mnt/c/progra~1/java/jdk-16/bin/javac: No such file or directory > > Adding a .exe suffix to the javac path fixes this issue, which can be done just for WSL. This pull request has now been integrated. Changeset: 77a5b7b2 Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/77a5b7b27e36457cf63be45b3e4f120abad57d4a Stats: 20 lines in 1 file changed: 12 ins; 2 del; 6 mod 8269761: idea.sh missing .exe suffix when invoking javac on WSL Reviewed-by: mcimadamore, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4656 From egahlin at openjdk.java.net Wed Jul 7 14:31:50 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 7 Jul 2021 14:31:50 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v2] In-Reply-To: References: Message-ID: On Sun, 4 Jul 2021 08:32:03 GMT, Denghui Dong wrote: > ``` > Benchmark Mode Samples Score Score error Units > o.s.MyBenchmark.testEmit thrpt 20 8251457.275 2707.578 ops/s > ``` > > without this patch: That sounds too much. Could you please show the test, so I could try it out. The large check should only happen once, so it is amortised. From that point on it should basically be the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From jwilhelm at openjdk.java.net Thu Jul 8 00:09:13 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 00:09:13 GMT Subject: RFR: Merge jdk17 Message-ID: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output - 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different - 8269879: [PPC64] C2: Math.rint intrinsic uses wrong rounding mode - 8266036: class file for sun.misc.Contended not found - 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available" - 8268859: jshell throws exception while parsing illegal "case true" - 8269802: javac fails to compile nested pattern matching switches - 8269830: SA's vm object vtable matching code sometimes matches on incorrect type - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4713/files Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod Patch: https://git.openjdk.java.net/jdk/pull/4713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713 PR: https://git.openjdk.java.net/jdk/pull/4713 From jwilhelm at openjdk.java.net Thu Jul 8 01:01:08 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 01:01:08 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Message-ID: On Thu, 8 Jul 2021 00:01:43 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 270fbcb3 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/270fbcb3f5755baf045fa6dec3fba459d32c32e1 Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4713 From jwilhelm at openjdk.java.net Thu Jul 8 01:01:07 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Thu, 8 Jul 2021 01:01:07 GMT Subject: RFR: Merge jdk17 [v2] In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com> Message-ID: > Forwardport JDK 17 -> JDK 18 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits: - Merge - 8264735: Make dynamic dump repeatable Reviewed-by: ccheung, iklam - 8269481: SctpMultiChannel never releases own file descriptor Reviewed-by: alanb, chegar - 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64 Reviewed-by: mgronlun - 8267303: Replace MinObjectAlignmentSize usages for non-Java heap objects Reviewed-by: kbarrett, tschatzl, minqi - 8268635: Corrupt oop in ClassLoaderData Reviewed-by: iklam, dholmes - 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation" Reviewed-by: dcubed, dholmes - 8269761: idea.sh missing .exe suffix when invoking javac on WSL Reviewed-by: mcimadamore, erikj - 8269294: Verify_before/after_young_collection should execute all verification Reviewed-by: iwalulya, kbarrett - 8269908: Move MemoryService::track_memory_usage call into G1MonitoringScope Reviewed-by: ayang, kbarrett - ... and 170 more: https://git.openjdk.java.net/jdk/compare/c812bbbe...e5695159 ------------- Changes: https://git.openjdk.java.net/jdk/pull/4713/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=01 Stats: 46991 lines in 850 files changed: 21189 ins; 22881 del; 2921 mod Patch: https://git.openjdk.java.net/jdk/pull/4713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713 PR: https://git.openjdk.java.net/jdk/pull/4713 From ddong at openjdk.java.net Thu Jul 8 02:47:46 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 8 Jul 2021 02:47:46 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jul 2021 06:19:07 GMT, Denghui Dong wrote: >> Hi, >> >> Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? >> >> JDK-8246260 introduced event large checks to reduce the recording size. >> This check could be eliminated at compile/build time when one of the following conditions is satisfied: >> 1. if the max size is < 128 >> 2. if the min size is >= 128 >> >> The max size and the min size could be computed for the most native events at the generation phase. >> >> And I think this improvement may also be done for JDK events. > > Denghui Dong has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. diff --git a/src/hotspot/share/jfr/jni/jfrJniMethod.cpp b/src/hotspot/share/jfr/jni/jfrJniMethod.cpp index 54a4680ced8..893aaebdbd6 100644 --- a/src/hotspot/share/jfr/jni/jfrJniMethod.cpp +++ b/src/hotspot/share/jfr/jni/jfrJniMethod.cpp @@ -362,3 +362,11 @@ JVM_END JVM_ENTRY_NO_ENV(jboolean, jfr_set_handler(JNIEnv * env, jobject jvm, jobject clazz, jobject handler)) return JfrJavaSupport::set_handler(clazz, handler, thread); JVM_END + +JVM_ENTRY_NO_ENV(void, jfr_emit(JNIEnv* env, jobject jvm)) + for (int i = 0; i < 100; i++) { + EventTest e; + e.set_dummy(1); + e.commit(); + } +JVM_END diff --git a/src/hotspot/share/jfr/jni/jfrJniMethod.hpp b/src/hotspot/share/jfr/jni/jfrJniMethod.hpp index 19a676c4a22..7da213c80c1 100644 --- a/src/hotspot/share/jfr/jni/jfrJniMethod.hpp +++ b/src/hotspot/share/jfr/jni/jfrJniMethod.hpp @@ -152,6 +152,8 @@ jboolean JNICALL jfr_set_handler(JNIEnv* env, jobject jvm, jobject clazz, jobjec jlong JNICALL jfr_get_type_id_from_string(JNIEnv* env, jobject jvm, jstring type); +void JNICALL jfr_emit(JNIEnv*, jobject jvm); + #ifdef __cplusplus } #endif diff --git a/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp b/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp index db137776f65..1aab7909f6e 100644 --- a/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp +++ b/src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp @@ -90,7 +90,8 @@ JfrJniMethodRegistration::JfrJniMethodRegistration(JNIEnv* env) { (char*)"getChunkStartNanos", (char*)"()J", (void*)jfr_chunk_start_nanos, (char*)"getHandler", (char*)"(Ljava/lang/Class;)Ljava/lang/Object;", (void*)jfr_get_handler, (char*)"setHandler", (char*)"(Ljava/lang/Class;Ljdk/jfr/internal/handlers/EventHandler;)Z", (void*)jfr_set_handler, - (char*)"getTypeId", (char*)"(Ljava/lang/String;)J", (void*)jfr_get_type_id_from_string + (char*)"getTypeId", (char*)"(Ljava/lang/String;)J", (void*)jfr_get_type_id_from_string, + (char*)"emit", (char*)"()V", (void*)jfr_emit, }; const size_t method_array_length = sizeof(method) / sizeof(JNINativeMethod); diff --git a/src/hotspot/share/jfr/metadata/metadata.xml b/src/hotspot/share/jfr/metadata/metadata.xml index 1a19b763314..633c6e3f1f1 100644 --- a/src/hotspot/share/jfr/metadata/metadata.xml +++ b/src/hotspot/share/jfr/metadata/metadata.xml @@ -1081,6 +1081,10 @@ + + + + diff --git a/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java b/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java index a88b428dac3..bd28e5b4015 100644 --- a/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java +++ b/src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java @@ -597,4 +597,6 @@ public final class JVM { * @return the id, or a negative value if it does not exists. */ public native long getTypeId(String name); + + public native void emit(); } It's a simple benchmark, I wrote a native function to emit 100 same native events. package org.sample; import jdk.jfr.Event; import jdk.jfr.Recording; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.Fork; import org.openjdk.jmh.annotations.Warmup; import org.openjdk.jmh.annotations.Setup; import org.openjdk.jmh.annotations.*; import org.openjdk.jmh.infra.Blackhole; import jdk.jfr.internal.JVM; @State(Scope.Benchmark) public class MyBenchmark { @Benchmark @Fork(value=1, jvmArgs = {"--add-exports", "jdk.jfr/jdk.jfr.internal=ALL-UNNAMED"}) @Warmup(iterations = 5, time = 1) public void testEmit(Blackhole bh) { JVM.getJVM().emit(); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Thu Jul 8 02:54:50 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 8 Jul 2021 02:54:50 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 14:28:27 GMT, Erik Gahlin wrote: > The large check should only happen once `if (written > 127) {` in EventWriterHost::end_event_write could also be eliminated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Thu Jul 8 04:46:18 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 8 Jul 2021 04:46:18 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v5] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? > > JDK-8246260 introduced event large checks to reduce the recording size. > This check could be eliminated at compile/build time when one of the following conditions is satisfied: > 1. if the max size is < 128 > 2. if the min size is >= 128 > > The max size and the min size could be computed for the most native events at the generation phase. > > And I think this improvement may also be done for JDK events. Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4670/files - new: https://git.openjdk.java.net/jdk/pull/4670/files/e8fdcb54..cf13965a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4670&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4670/head:pull/4670 PR: https://git.openjdk.java.net/jdk/pull/4670 From ddong at openjdk.java.net Thu Jul 8 09:48:22 2021 From: ddong at openjdk.java.net (Denghui Dong) Date: Thu, 8 Jul 2021 09:48:22 GMT Subject: RFR: 8269823: JFR: Eliminate 'is_large' check for native JFR event if the size range is certain [v5] In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 04:46:18 GMT, Denghui Dong wrote: >> Hi, >> >> Could I have a review of this improvement that eliminates 'is_large' check if the event size range is certain? >> >> JDK-8246260 introduced event large checks to reduce the recording size. >> This check could be eliminated at compile/build time when one of the following conditions is satisfied: >> 1. if the max size is < 128 >> 2. if the min size is >= 128 >> >> The max size and the min size could be computed for the most native events at the generation phase. >> >> And I think this improvement may also be done for JDK events. > > Denghui Dong has updated the pull request incrementally with one additional commit since the last revision: > > fix hmm, sorry, my previous benchmark result is tested without enabling the event. The following are the latest test results on Linux x86_64: with the patch: Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.testEmit thrpt 20 250838.078 1850.396 ops/s without the patch: Benchmark Mode Samples Score Score error Units o.s.MyBenchmark.testEmit thrpt 20 239574.823 1242.553 ops/s ------------- PR: https://git.openjdk.java.net/jdk/pull/4670 From ysuenaga at openjdk.java.net Thu Jul 8 12:05:07 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 8 Jul 2021 12:05:07 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 Message-ID: I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: ------------- Commit messages: - 8270083: -Wnonnull errors happen with GCC 11.1.1 Changes: https://git.openjdk.java.net/jdk/pull/4719/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4719&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270083 Stats: 42 lines in 9 files changed: 38 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/4719.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4719/head:pull/4719 PR: https://git.openjdk.java.net/jdk/pull/4719 From erikj at openjdk.java.net Thu Jul 8 18:05:55 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Jul 2021 18:05:55 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: Build change looks good. Can't comment on the code changes. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4719 From shurailine at openjdk.java.net Thu Jul 8 19:07:07 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Thu, 8 Jul 2021 19:07:07 GMT Subject: RFR: JDK-8270108: Update JCov version to 3.0.9 Message-ID: JDK-8270108: Update JCov version to 3.0.9 ------------- Commit messages: - JDK-8270108: Update JCov version to 3.0.9 Changes: https://git.openjdk.java.net/jdk/pull/4729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270108 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4729/head:pull/4729 PR: https://git.openjdk.java.net/jdk/pull/4729 From dlong at openjdk.java.net Thu Jul 8 20:46:56 2021 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 8 Jul 2021 20:46:56 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From serb at openjdk.java.net Thu Jul 8 21:14:55 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Jul 2021 21:14:55 GMT Subject: RFR: JDK-8270108: Update JCov version to 3.0.9 In-Reply-To: References: Message-ID: <3D_R96D7cTIosyUjaQOM9G06qhRIdz8MQt3KUmmfwqI=.a4f2579b-946d-4b4f-a404-7dd0172006be@github.com> On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote: > JDK-8270108: Update JCov version to 3.0.9 Will it support the new class file format in jdk18? ------------- PR: https://git.openjdk.java.net/jdk/pull/4729 From kbarrett at openjdk.java.net Thu Jul 8 21:41:47 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 8 Jul 2021 21:41:47 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: This _might_ be good enough as a short-term workaround, but it should not be considered a long-term fix. The underlying problem really needs to be addressed properly. ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From dlong at openjdk.java.net Thu Jul 8 22:30:50 2021 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 8 Jul 2021 22:30:50 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: I agree, it would be good to fix the underlying problem without causing a performance regression. Maybe storing the register encoding as a field inside class RegisterImpl and using constexpr would work, or is there a better solution? ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From shurailine at openjdk.java.net Thu Jul 8 23:03:51 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Thu, 8 Jul 2021 23:03:51 GMT Subject: RFR: JDK-8270108: Update JCov version to 3.0.9 In-Reply-To: <3D_R96D7cTIosyUjaQOM9G06qhRIdz8MQt3KUmmfwqI=.a4f2579b-946d-4b4f-a404-7dd0172006be@github.com> References: <3D_R96D7cTIosyUjaQOM9G06qhRIdz8MQt3KUmmfwqI=.a4f2579b-946d-4b4f-a404-7dd0172006be@github.com> Message-ID: On Thu, 8 Jul 2021 21:11:23 GMT, Sergey Bylokhov wrote: > Will it support the new class file format in jdk18? Yes, this is the reason for the fix ------------- PR: https://git.openjdk.java.net/jdk/pull/4729 From serb at openjdk.java.net Thu Jul 8 23:14:54 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Jul 2021 23:14:54 GMT Subject: RFR: JDK-8270108: Update JCov version to 3.0.9 In-Reply-To: References: Message-ID: <_2HYywTZrvqS7CTAuQ2xU1AeTxOCewaSy7EVcxK9TEM=.64eb6fab-a643-4f63-8dc3-39c12962c197@github.com> On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote: > JDK-8270108: Update JCov version to 3.0.9 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4729 From erikj at openjdk.java.net Thu Jul 8 23:19:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Jul 2021 23:19:50 GMT Subject: RFR: JDK-8270108: Update JCov version to 3.0.9 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote: > JDK-8270108: Update JCov version to 3.0.9 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4729 From ysuenaga at openjdk.java.net Fri Jul 9 00:31:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 9 Jul 2021 00:31:52 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: It is better if we can treat registers as a class **normally**. Similar change happens for markWord in [JDK-8229258](https://bugs.openjdk.java.net/browse/JDK-8229258). Should we change like now? ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From dlong at openjdk.java.net Fri Jul 9 04:07:49 2021 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 9 Jul 2021 04:07:49 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 00:28:38 GMT, Yasumasa Suenaga wrote: >> I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: > > It is better if we can treat registers as a class **normally**. Similar change happens for markWord in [JDK-8229258](https://bugs.openjdk.java.net/browse/JDK-8229258). Should we change like now? @YaSuenag I'm in favor of a permanent solution, assuming there's no regression in footprint or code quality. See https://bugs.openjdk.java.net/browse/JDK-8269122 for a related improvement. ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From kbarrett at openjdk.java.net Fri Jul 9 04:35:50 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 9 Jul 2021 04:35:50 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: I'm conditionally approving this as a temporary workaround. A followup RFE to improve things should be filed. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4719 From kbarrett at openjdk.java.net Fri Jul 9 04:35:50 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 9 Jul 2021 04:35:50 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 00:28:38 GMT, Yasumasa Suenaga wrote: > It is better if we can treat registers as a class **normally**. Similar change happens for markWord in [JDK-8229258](https://bugs.openjdk.java.net/browse/JDK-8229258). Should we change like now? The potential difficulty with doing that is the same as for markWord - see [JDK-8235362](https://bugs.openjdk.java.net/browse/JDK-8235362). A different option might be to make the various categories of Register be enum classes without any defined enumerators. That wouldn't support the existing XXXRegisterImpl derivation from AbstractRegisterImpl. I'm not sure that relationship is needed; it may not even be good. The only use I can find is in the various assert_different_registers, and that could be done differently. (The numerous overloads could also probably be simplified using variadic templates.) ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From ysuenaga at openjdk.java.net Fri Jul 9 05:59:53 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 9 Jul 2021 05:59:53 GMT Subject: RFR: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:02:55 GMT, Erik Joelsson wrote: >> I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: > > Build change looks good. Can't comment on the code changes. Thanks @erikj79 @dean-long @kimbarrett to approve this change! I filed a followup RFE as [JDK-8270140](https://bugs.openjdk.java.net/browse/JDK-8270140). I will integrate this change later. ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From shurailine at openjdk.java.net Fri Jul 9 18:32:54 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Fri, 9 Jul 2021 18:32:54 GMT Subject: Integrated: JDK-8270108: Update JCov version to 3.0.9 In-Reply-To: References: Message-ID: On Thu, 8 Jul 2021 18:59:56 GMT, Alexandre Iline wrote: > JDK-8270108: Update JCov version to 3.0.9 This pull request has now been integrated. Changeset: 7bfa39f5 Author: Alexandre Iline URL: https://git.openjdk.java.net/jdk/commit/7bfa39f59a745b562355436f9eb91992dbe243b2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8270108: Update JCov version to 3.0.9 Reviewed-by: serb, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/4729 From erikj at openjdk.java.net Fri Jul 9 19:40:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 9 Jul 2021 19:40:53 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 19:02:04 GMT, Erik Joelsson wrote: > This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. > > @hns Can you verify that this solves the problem you reported? For some reason the build label wasn't added automatically, so looking for a build-dev review too. ------------- PR: https://git.openjdk.java.net/jdk17/pull/227 From erikj at openjdk.java.net Fri Jul 9 19:52:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 9 Jul 2021 19:52:05 GMT Subject: [jdk17] RFR: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot Message-ID: Add missing make dependency in Main.gmk. ------------- Commit messages: - JDK-8270203 Changes: https://git.openjdk.java.net/jdk17/pull/239/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=239&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270203 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk17/pull/239.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/239/head:pull/239 PR: https://git.openjdk.java.net/jdk17/pull/239 From jjg at openjdk.java.net Fri Jul 9 20:20:56 2021 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Fri, 9 Jul 2021 20:20:56 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links In-Reply-To: References: Message-ID: <3w3TH08lxtX7PrcbPYg24c43umx_xydxvioo4esLjwA=.719afb45-164e-456e-821a-51cd2c2134cd@github.com> On Wed, 7 Jul 2021 19:02:04 GMT, Erik Joelsson wrote: > This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. > > @hns Can you verify that this solves the problem you reported? Generally, looks good. Thanks for the general cleanup to prevailing standards. The work looks OK, but I don't consider myself a build-Reviewer. Note to self: it might be interesting to figure out exactly how we might routinely test this feature. make/modules/jdk.javadoc/Gendata.gmk line 86: > 84: 11 \ > 85: ) > 86: # Generate element-list file for the current JDK version Is this indentation as intended? ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/227 From ysuenaga at openjdk.java.net Sat Jul 10 05:04:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 10 Jul 2021 05:04:58 GMT Subject: Integrated: 8270083: -Wnonnull errors happen with GCC 11.1.1 In-Reply-To: References: Message-ID: <9x39bpx0Vb4Xd4snMsaUEza_inopGhThmnmnMVGI_7E=.fafa5a94-be02-443a-b402-7d8b5b974d2e@github.com> On Thu, 8 Jul 2021 09:42:43 GMT, Yasumasa Suenaga wrote: > I attempted to build OpenJDK on Fedora 34 with gcc-11.1.1-3.fc34.x86_64, but I saw following errors: > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/runtime/frame.inline.hpp:42, > from /home/ysuenaga/github-forked/jdk/src/hotspot/cpu/x86/abstractInterpreter_x86.cpp:29: This pull request has now been integrated. Changeset: 68b6e11e Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/68b6e11e481349e40014aa4593a53ae2ea74aedc Stats: 42 lines in 9 files changed: 38 ins; 0 del; 4 mod 8270083: -Wnonnull errors happen with GCC 11.1.1 Reviewed-by: erikj, dlong, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/4719 From tbell at openjdk.java.net Sun Jul 11 03:20:15 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Sun, 11 Jul 2021 03:20:15 GMT Subject: [jdk17] RFR: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 19:45:09 GMT, Erik Joelsson wrote: > Add missing make dependency in Main.gmk. Looks good ------------- Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/239 From ihse at openjdk.java.net Mon Jul 12 11:18:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 12 Jul 2021 11:18:07 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links In-Reply-To: References: Message-ID: On Wed, 7 Jul 2021 19:02:04 GMT, Erik Joelsson wrote: > This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. > > @hns Can you verify that this solves the problem you reported? Overall it looks good. Thanks for cleaning up the bad code that inadvertently slipped in. One final remark regarding the marker files `_element_lists`. I've tried to use the naming pattern `_.marker` for new marker files, to give them a clear file type suffix. Converting all old names is a slow process, but I'd appreciate it if new files follow this pattern. make/modules/jdk.javadoc/Gendata.gmk line 84: > 82: $(CT_DATA_DESCRIPTION) \ > 83: $(ELEMENT_LISTS_DIR) \ > 84: 11 \ I'm not sure why JDK 11 is chosen as the starting point, but I suspect it might change in the future. Perhaps move this to a variable instead of hardcoding it into the command line, so it's more visible? make/modules/jdk.javadoc/Gendata.gmk line 107: > 105: $(RM) -r $(INTERIM_ELEMENT_LISTS_DIR) > 106: $(MKDIR) -p $(INTERIM_ELEMENT_LISTS_DIR) > 107: $(CP) -R $(ELEMENT_LISTS_DIR)/* $(INTERIM_ELEMENT_LISTS_DIR)/ If you instead do $(call MakeDir $(INTERIM_ELEMENT_LISTS_DIR)) $(RM) -r $(INTERIM_ELEMENT_LISTS_DIR)/* we can save a makedir on rebuilds. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/227 From matthias.baesken at sap.com Mon Jul 12 11:26:50 2021 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Jul 2021 11:26:50 +0000 Subject: Building OpenJDK with Xcode12 devkits on older macOS Message-ID: Hello, I noticed the following when building jdk on macOS 10.14 with xcode12 devkit . The tool "xcodebuild" which is used at some places in the configure process (see basic.m4 / toolchain.m4) fails because of the too old macOS : configure:70788: xcodebuild output: dyld: Library not loaded: /System/Library/Frameworks/Combine.framework/Versions/A/Combine configure:70790: error: Failed to determine Xcode version. But when I rename/remove the xcodebuild from the devkit, the builds work perfectly fine (because the compilers do not have these deps to Combine.framework). So I wonder - is there a "nicer" way to achieve this without renaming/removing the xcodebuild tool from the devkit (e.g. by setting other configure options or env variables) ? Thanks, Matthias From ihse at openjdk.java.net Mon Jul 12 12:31:56 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 12 Jul 2021 12:31:56 GMT Subject: [jdk17] RFR: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot In-Reply-To: References: Message-ID: <2l3GPBXAlXF6hSd4v2ekto9Hbyy-6X_SRoi37dajQso=.f5e39f23-d73f-441b-857d-33775cd2fdac@github.com> On Fri, 9 Jul 2021 19:45:09 GMT, Erik Joelsson wrote: > Add missing make dependency in Main.gmk. Changes requested by ihse (Reviewer). make/Main.gmk line 860: > 858: jdk.jdwp.agent-libs: jdk.jdwp.agent-gensrc > 859: > 860: # jdk.jfr-gensrc uses TOOL_JFR_GEN from buildtools-hotspot The comment and the code do not match. I assume the comment is incorrect. ------------- PR: https://git.openjdk.java.net/jdk17/pull/239 From ihse at openjdk.java.net Mon Jul 12 13:27:44 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 12 Jul 2021 13:27:44 GMT Subject: RFR: 8270117: Broken jtreg link in "Building the JDK" page Message-ID: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> Paraphrased description from the bug report: The "Building the JDK" page has a jtreg download link pointing to but that gets a 404. I believe the correct link is , which is not all that easy to find. ------------- Commit messages: - 8270117: Broken jtreg link in "Building the JDK" page Changes: https://git.openjdk.java.net/jdk/pull/4754/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4754&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270117 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4754/head:pull/4754 PR: https://git.openjdk.java.net/jdk/pull/4754 From sgehwolf at openjdk.java.net Mon Jul 12 15:13:55 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 12 Jul 2021 15:13:55 GMT Subject: RFR: 8270117: Broken jtreg link in "Building the JDK" page In-Reply-To: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> References: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> Message-ID: On Mon, 12 Jul 2021 13:17:18 GMT, Magnus Ihse Bursie wrote: > Paraphrased description from the bug report: > > The "Building the JDK" page has a jtreg download link pointing to but that gets a 404. I believe the correct link is , which is not all that easy to find. Changes requested by sgehwolf (Reviewer). doc/building.md line 851: > 849: The [Adoption Group](https://wiki.openjdk.java.net/display/Adoption) provides > 850: recent builds of jtreg [here]( > 851: https://ci.adoptopenjdk.net/view/work-in-progress/job/GetNode/lastSuccessfulBuild/artifact/). The right link is: https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/lastSuccessfulBuild/artifact/jtreg/ ------------- PR: https://git.openjdk.java.net/jdk/pull/4754 From ihse at openjdk.java.net Mon Jul 12 17:41:27 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 12 Jul 2021 17:41:27 GMT Subject: RFR: 8270117: Broken jtreg link in "Building the JDK" page [v2] In-Reply-To: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> References: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> Message-ID: > Paraphrased description from the bug report: > > The "Building the JDK" page has a jtreg download link pointing to but that gets a 404. I believe the correct link is , which is not all that easy to find. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use link suggested by Severin instead ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4754/files - new: https://git.openjdk.java.net/jdk/pull/4754/files/10ba6223..5f00e605 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4754&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4754&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4754/head:pull/4754 PR: https://git.openjdk.java.net/jdk/pull/4754 From sgehwolf at openjdk.java.net Mon Jul 12 18:13:54 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 12 Jul 2021 18:13:54 GMT Subject: RFR: 8270117: Broken jtreg link in "Building the JDK" page [v2] In-Reply-To: References: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> Message-ID: On Mon, 12 Jul 2021 17:41:27 GMT, Magnus Ihse Bursie wrote: >> Paraphrased description from the bug report: >> >> The "Building the JDK" page has a jtreg download link pointing to but that gets a 404. I believe the correct link is , which is not all that easy to find. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use link suggested by Severin instead LGTM. ------------- Marked as reviewed by sgehwolf (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4754 From ihse at openjdk.java.net Mon Jul 12 18:20:57 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 12 Jul 2021 18:20:57 GMT Subject: Integrated: 8270117: Broken jtreg link in "Building the JDK" page In-Reply-To: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> References: <4nQSurYA02gzcbq5cB0PRdKy3DK5p1rFwLMADBt_k7A=.c593876c-931b-4ce1-9def-74d9a969248f@github.com> Message-ID: <_Bt57p-7DpCNI6immE9R7Pm56A4xA8NkBSaN7WxiGQY=.09ef272c-24c9-476a-9ac1-3e1c59dc827c@github.com> On Mon, 12 Jul 2021 13:17:18 GMT, Magnus Ihse Bursie wrote: > Paraphrased description from the bug report: > > The "Building the JDK" page has a jtreg download link pointing to but that gets a 404. I believe the correct link is , which is not all that easy to find. This pull request has now been integrated. Changeset: 41a5eb43 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/41a5eb437204a650d6cc271f41e1d186ee812a88 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8270117: Broken jtreg link in "Building the JDK" page Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.java.net/jdk/pull/4754 From erik.joelsson at oracle.com Tue Jul 13 05:50:59 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 13 Jul 2021 07:50:59 +0200 Subject: Building OpenJDK with Xcode12 devkits on older macOS In-Reply-To: References: Message-ID: <347b0967-1eef-f022-cc8c-df0fd51632c2@oracle.com> Hello Matthias, I don't know of a nicer way. I have just assumed that the build won't work on a Macos version older than what the Xcode in the kit officially supports. /Erik On 2021-07-12 04:26, Baesken, Matthias wrote: > Hello, I noticed the following when building jdk on macOS 10.14 with xcode12 devkit . > The tool "xcodebuild" which is used at some places in the configure process (see basic.m4 / toolchain.m4) fails because of the too old macOS : > > configure:70788: xcodebuild output: dyld: Library not loaded: /System/Library/Frameworks/Combine.framework/Versions/A/Combine > configure:70790: error: Failed to determine Xcode version. > > But when I rename/remove the xcodebuild from the devkit, the builds work perfectly fine (because the compilers do not have these deps to Combine.framework). > So I wonder - is there a "nicer" way to achieve this without renaming/removing the xcodebuild tool from the devkit (e.g. by setting other configure options or env variables) ? > > > Thanks, Matthias > > > From erikj at openjdk.java.net Tue Jul 13 05:58:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 05:58:21 GMT Subject: [jdk17] RFR: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot [v2] In-Reply-To: References: Message-ID: > Add missing make dependency in Main.gmk. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fix comment ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/239/files - new: https://git.openjdk.java.net/jdk17/pull/239/files/6e65e741..0a7aeef9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=239&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=239&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/239.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/239/head:pull/239 PR: https://git.openjdk.java.net/jdk17/pull/239 From erikj at openjdk.java.net Tue Jul 13 05:58:23 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 05:58:23 GMT Subject: [jdk17] Integrated: 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 19:45:09 GMT, Erik Joelsson wrote: > Add missing make dependency in Main.gmk. This pull request has now been integrated. Changeset: 0f329828 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk17/commit/0f32982872eb1454e55390760b65beb5838afc55 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot Reviewed-by: tbell ------------- PR: https://git.openjdk.java.net/jdk17/pull/239 From jpai at openjdk.java.net Tue Jul 13 07:07:00 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 13 Jul 2021 07:07:00 GMT Subject: RFR: 8268860: Windows-Aarch64 build is failing in GitHub actions In-Reply-To: <98J3oNKgWXFkB4_eI2q3LISBi0zdz4TePR1bjtz5pUQ=.f3619da8-ff92-4e78-9301-5c0b2be7a009@github.com> References: <98J3oNKgWXFkB4_eI2q3LISBi0zdz4TePR1bjtz5pUQ=.f3619da8-ff92-4e78-9301-5c0b2be7a009@github.com> Message-ID: On Mon, 5 Jul 2021 21:46:26 GMT, David Holmes wrote: > It is still unsettling that we don't know what changed More as an FYI and something that might help investigate similar failures in future. Each run of the GitHub action job generates a log which is available for download publicly (and/or can be viewed raw in the browser). For example, I just picked a random PR in the current queue https://github.com/openjdk/jdk/pull/4759 and clicked the "Details" link beside the "Pre-submit tests - Windows aarch64 - Build" under GitHub actions on that PR. Then click on the "Windows aarch64 (build debug)" link on that job run page. On the page that shows up, there's a visual log viewer of that job run. There's a "..." top right of that widget, which has an option which allows you to view the raw logs in the browser. Doing so will show the entire log of that run. One part of the log contains details about the virtual environment used for that run and it has some interesting/useful details like: 2021-07-12T20:41:25.6215958Z ##[group]Virtual Environment 2021-07-12T20:41:25.6216502Z Environment: windows-2019 2021-07-12T20:41:25.6216982Z Version: 20210628.1 2021-07-12T20:41:25.6217813Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20210628.1/images/win/Windows2019-Readme.md 2021-07-12T20:41:25.6219152Z Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20210628.1 2021-07-12T20:41:25.6219863Z ##[endgroup] So the details about the virtual environment used for that run are listed in the log and additional a (version controlled) link is provided which has the full list of softwares that were installed on that VM: > 2021-07-12T20:41:25.6217813Z Included Software: https://github.com/actions/virtual-environments/blob/win19/20210628.1/images/win/Windows2019-Readme.md This is a version controlled file and available in their github repo for public access as well as review. The commit history shows the exact version of which software changed over time. I don't know when the Windows-Aarch64 build started failing first, otherwise we could probably check the history on that file around that time to know what exactly caused this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4681 From erikj at openjdk.java.net Tue Jul 13 07:35:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 07:35:54 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links In-Reply-To: References: Message-ID: On Mon, 12 Jul 2021 11:10:26 GMT, Magnus Ihse Bursie wrote: >> This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. >> >> @hns Can you verify that this solves the problem you reported? > > make/modules/jdk.javadoc/Gendata.gmk line 84: > >> 82: $(CT_DATA_DESCRIPTION) \ >> 83: $(ELEMENT_LISTS_DIR) \ >> 84: 11 \ > > I'm not sure why JDK 11 is chosen as the starting point, but I suspect it might change in the future. Perhaps move this to a variable instead of hardcoding it into the command line, so it's more visible? I believe it's because earlier JDK versions have static lists in the repo. ------------- PR: https://git.openjdk.java.net/jdk17/pull/227 From erikj at openjdk.java.net Tue Jul 13 08:09:49 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 08:09:49 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links In-Reply-To: <3w3TH08lxtX7PrcbPYg24c43umx_xydxvioo4esLjwA=.719afb45-164e-456e-821a-51cd2c2134cd@github.com> References: <3w3TH08lxtX7PrcbPYg24c43umx_xydxvioo4esLjwA=.719afb45-164e-456e-821a-51cd2c2134cd@github.com> Message-ID: <3UapnZJEqgGxZO70WXKq9vXj6kvSi14vbej4yakllqQ=.4f8aa5f5-f534-4415-b932-ef6e3d875e47@github.com> On Fri, 9 Jul 2021 20:13:56 GMT, Jonathan Gibbons wrote: >> This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. >> >> @hns Can you verify that this solves the problem you reported? > > make/modules/jdk.javadoc/Gendata.gmk line 86: > >> 84: 11 \ >> 85: ) >> 86: # Generate element-list file for the current JDK version > > Is this indentation as intended? It looks weird in the GitHub web UI. I think they have a different setting for . We assume 8 spaces for and align lines that need to be space indented that way. Comments inside recipes need to be space indented so that they are not interpreted as recipe lines. ------------- PR: https://git.openjdk.java.net/jdk17/pull/227 From erikj at openjdk.java.net Tue Jul 13 08:26:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 08:26:21 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links [v2] In-Reply-To: References: Message-ID: <-mbIO-OuVVbodUX6Nzla0m_WknoIhwVersnASzJ2BIM=.c8f68fcb-ce2c-49cf-a445-0eb49a2a0d08@github.com> > This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. > > @hns Can you verify that this solves the problem you reported? Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk17/pull/227/files - new: https://git.openjdk.java.net/jdk17/pull/227/files/6c09fef2..64864831 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=227&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=227&range=00-01 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk17/pull/227.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/227/head:pull/227 PR: https://git.openjdk.java.net/jdk17/pull/227 From ihse at openjdk.java.net Tue Jul 13 08:53:55 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 13 Jul 2021 08:53:55 GMT Subject: [jdk17] RFR: 8259848: Interim javadoc build does not support platform links [v2] In-Reply-To: <-mbIO-OuVVbodUX6Nzla0m_WknoIhwVersnASzJ2BIM=.c8f68fcb-ce2c-49cf-a445-0eb49a2a0d08@github.com> References: <-mbIO-OuVVbodUX6Nzla0m_WknoIhwVersnASzJ2BIM=.c8f68fcb-ce2c-49cf-a445-0eb49a2a0d08@github.com> Message-ID: On Tue, 13 Jul 2021 08:26:21 GMT, Erik Joelsson wrote: >> This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. >> >> @hns Can you verify that this solves the problem you reported? > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/227 From erikj at openjdk.java.net Tue Jul 13 09:30:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 13 Jul 2021 09:30:53 GMT Subject: [jdk17] Integrated: 8259848: Interim javadoc build does not support platform links In-Reply-To: References: Message-ID: <4WYTLZnw68zgKf_8ZkjqzwT2CQjGwaY9MC_t1tAHFEU=.871f56ce-b6d0-4392-aee1-959033b372a1@github.com> On Wed, 7 Jul 2021 19:02:04 GMT, Erik Joelsson wrote: > This patch adds copying of element-list files generated for jdk.javadoc to the interim langtools version of jdk.javadoc. I'm also refactoring the jdk.javadoc/Gendata.gmk file a bit to better adhere to current build infra standards as this was missed in the original review of this file. Rebuilding should now work better with the various clean targets and any problems with the generation tool will be captured in separate log files, along with the command lines. > > @hns Can you verify that this solves the problem you reported? This pull request has now been integrated. Changeset: e631addd Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk17/commit/e631addd70437c776eeeb481e0b44f1d0fd22fe8 Stats: 46 lines in 1 file changed: 21 ins; 3 del; 22 mod 8259848: Interim javadoc build does not support platform links Reviewed-by: hannesw, jjg, ihse ------------- PR: https://git.openjdk.java.net/jdk17/pull/227 From jwilhelm at openjdk.java.net Wed Jul 14 00:22:49 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 14 Jul 2021 00:22:49 GMT Subject: RFR: Merge jdk17 Message-ID: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com> Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE - 8270184: [TESTBUG] Add coverage for jvmci ResolvedJavaType.toJavaName() for lambdas - 8269281: java/foreign/Test{Down,Up}call.java time out - 8269635: Stress test SEGV while emitting OldObjectSample - 8269525: Deadlock during Volano with JFR - 8259848: Interim javadoc build does not support platform links - 8269795: C2: Out of bounds array load floats above its range check in loop peeling resulting in SEGV - 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4771&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4771&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4771/files Stats: 388 lines in 13 files changed: 322 ins; 18 del; 48 mod Patch: https://git.openjdk.java.net/jdk/pull/4771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4771/head:pull/4771 PR: https://git.openjdk.java.net/jdk/pull/4771 From jwilhelm at openjdk.java.net Wed Jul 14 01:10:29 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 14 Jul 2021 01:10:29 GMT Subject: Integrated: Merge jdk17 In-Reply-To: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com> References: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com> Message-ID: <5EuAHb-D3XlzTzriaMpMRYvuN7F7Rsga91-2nbN_X1s=.639bf5f5-df8a-4dbf-bd9c-efe2b21a5cbe@github.com> On Wed, 14 Jul 2021 00:13:41 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 4a7ccf36 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/4a7ccf36e9a3978c437db3efe892dd23e8a0b772 Stats: 388 lines in 13 files changed: 322 ins; 18 del; 48 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4771 From erikj at openjdk.java.net Wed Jul 14 07:42:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 14 Jul 2021 07:42:25 GMT Subject: [jdk17] RFR: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848 Message-ID: This patch extends the filter for marker files when creating jmods. Our latest established marker file format is `_*.marker` and through ExecuteWithLog, we regularly append additional suffixes to such file names. Thus I propose we simply extend the filter pattern to `_*.marker*`. ------------- Commit messages: - JDK-8270422 Changes: https://git.openjdk.java.net/jdk17/pull/249/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=249&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270422 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk17/pull/249.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/249/head:pull/249 PR: https://git.openjdk.java.net/jdk17/pull/249 From mikael at openjdk.java.net Wed Jul 14 10:59:12 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 14 Jul 2021 10:59:12 GMT Subject: [jdk17] RFR: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848 In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 07:34:58 GMT, Erik Joelsson wrote: > This patch extends the filter for marker files when creating jmods. Our latest established marker file format is `_*.marker` and through ExecuteWithLog, we regularly append additional suffixes to such file names. Thus I propose we simply extend the filter pattern to `_*.marker*`. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/249 From erikj at openjdk.java.net Wed Jul 14 13:04:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 14 Jul 2021 13:04:21 GMT Subject: [jdk17] Integrated: 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848 In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 07:34:58 GMT, Erik Joelsson wrote: > This patch extends the filter for marker files when creating jmods. Our latest established marker file format is `_*.marker` and through ExecuteWithLog, we regularly append additional suffixes to such file names. Thus I propose we simply extend the filter pattern to `_*.marker*`. This pull request has now been integrated. Changeset: 7b4d84c6 Author: Erik Joelsson URL: https://git.openjdk.java.net/jdk17/commit/7b4d84c65487593cdbf841f7f2d359192476db99 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk17/pull/249 From jwilhelm at openjdk.java.net Wed Jul 14 21:43:43 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 14 Jul 2021 21:43:43 GMT Subject: RFR: Merge jdk17 Message-ID: Forwardport JDK 17 -> JDK 18 ------------- Commit messages: - Merge - 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848 - 8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes - 8270075: SplittableRandom extends AbstractSplittableGenerator - 8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run - 8259499: Handling type arguments from outer classes for inner class in javadoc - 8268620: InfiniteLoopException test may fail on x86 platforms - 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX - 8270056: Generated lambda class can not access protected static method of target class The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4786&range=00.0 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4786&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/4786/files Stats: 328 lines in 19 files changed: 240 ins; 14 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/4786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4786/head:pull/4786 PR: https://git.openjdk.java.net/jdk/pull/4786 From jwilhelm at openjdk.java.net Wed Jul 14 22:41:17 2021 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Wed, 14 Jul 2021 22:41:17 GMT Subject: Integrated: Merge jdk17 In-Reply-To: References: Message-ID: On Wed, 14 Jul 2021 21:35:34 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 7d0edb57 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/7d0edb5743aacfc22f76ee8aa7b03d7dc0f90dca Stats: 328 lines in 19 files changed: 240 ins; 14 del; 74 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/4786 From aoqi at openjdk.java.net Thu Jul 15 04:10:21 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 04:10:21 GMT Subject: RFR: 8270517: Add Zero support for LoongArch Message-ID: LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. linux-loongarch64-zero-{release, fastdebug} build tested: $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version openjdk version "18-internal" 2022-03-15 OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) ------------- Commit messages: - 8270517: Add Zero support for LoongArch Changes: https://git.openjdk.java.net/jdk/pull/4787/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270517 Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787 PR: https://git.openjdk.java.net/jdk/pull/4787 From dholmes at openjdk.java.net Thu Jul 15 04:41:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 04:41:13 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) The hotspot changes seem fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From erikj at openjdk.java.net Thu Jul 15 06:35:13 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 15 Jul 2021 06:35:13 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: <_AMKiWZ9E5nHHsIv14njAJ0ZKFqFzkQb8IkVYPS16SQ=.01b5963d-6ea3-4db9-a186-3cf0f0e8c540@github.com> On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From shade at openjdk.java.net Thu Jul 15 06:41:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Jul 2021 06:41:14 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Looks good for me (from Zero maintenance standpoint). A minor suggestion below. src/hotspot/os/linux/os_linux.cpp line 1701: > 1699: {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, > 1700: {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISC-V"}, > 1701: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, Suggestion: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 07:27:11 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 07:27:11 GMT Subject: RFR: 8270517: Add Zero support for LoongArch In-Reply-To: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> References: <0TPPBbR-_VfALh6nIU_YF84iE0XywjXZq6bl4M0sZ9Q=.e163e50b-14c4-4d68-8c97-d5576dcc9292@github.com> Message-ID: On Thu, 15 Jul 2021 06:30:24 GMT, Aleksey Shipilev wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > src/hotspot/os/linux/os_linux.cpp line 1701: > >> 1699: {EM_AARCH64, EM_AARCH64, ELFCLASS64, ELFDATA2LSB, (char*)"AARCH64"}, >> 1700: {EM_RISCV, EM_RISCV, ELFCLASS64, ELFDATA2LSB, (char*)"RISC-V"}, >> 1701: {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, > > Suggestion: > > {EM_LOONGARCH, EM_LOONGARCH, ELFCLASS64, ELFDATA2LSB, (char*)"LoongArch"}, I added some additional whitespaces according to EM_MIPS_RS3_LE line, which is also too long. Your suggestion is fine to me. I will fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 07:42:33 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 07:42:33 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) Ao Qi has updated the pull request incrementally with one additional commit since the last revision: removed redundant whitespaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4787/files - new: https://git.openjdk.java.net/jdk/pull/4787/files/bd626159..5dbfe543 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4787&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4787.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4787/head:pull/4787 PR: https://git.openjdk.java.net/jdk/pull/4787 From dholmes at openjdk.java.net Thu Jul 15 07:57:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Jul 2021 07:57:12 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:15:17 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:15:17 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:54:41 GMT, David Holmes wrote: >> Ao Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> removed redundant whitespaces > > Marked as reviewed by dholmes (Reviewer). @dholmes-ora @erikj79 and @shipilev , thanks for the fast review! I also did a release bootcycle-images test and a jcstress test. They are passed. Could you help to sponsor it? ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:31:14 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:31:14 GMT Subject: Integrated: 8270517: Add Zero support for LoongArch In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 04:04:08 GMT, Ao Qi wrote: > LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. > > linux-loongarch64-zero-{release, fastdebug} build tested: > > $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version > openjdk version "18-internal" 2022-03-15 > OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) > OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) This pull request has now been integrated. Changeset: e92e2fd4 Author: Ao Qi Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e92e2fd4e0bc805d8f7d70f632cce0282eb1809b Stats: 22 lines in 3 files changed: 21 ins; 0 del; 1 mod 8270517: Add Zero support for LoongArch Reviewed-by: dholmes, erikj, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From shade at openjdk.java.net Thu Jul 15 08:31:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 15 Jul 2021 08:31:14 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces Oh wait, the PR is only 4 hours old, so I removed my `/sponsor` comment, but it was apparently too late. I should have waited for a bit longer. No harm seems to be done yet. We shall do any followups, if any problems arise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From aoqi at openjdk.java.net Thu Jul 15 08:38:16 2021 From: aoqi at openjdk.java.net (Ao Qi) Date: Thu, 15 Jul 2021 08:38:16 GMT Subject: RFR: 8270517: Add Zero support for LoongArch [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jul 2021 07:42:33 GMT, Ao Qi wrote: >> LoongArch is a new RISC ISA. This issue proposes adding Zero support for LoongArch. Only 64-bit support is proposed at present. >> >> linux-loongarch64-zero-{release, fastdebug} build tested: >> >> $ ./build/linux-loongarch64-zero-fastdebug/jdk/bin/java -version >> openjdk version "18-internal" 2022-03-15 >> OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.aoqi.jdk) >> OpenJDK 64-Bit Zero VM (fastdebug build 18-internal+0-adhoc.aoqi.jdk, interpreted mode) > > Ao Qi has updated the pull request incrementally with one additional commit since the last revision: > > removed redundant whitespaces I apologized that I type "/integrate" too early. I will pay close attention to this issue in the next few days in case any problems arise. ------------- PR: https://git.openjdk.java.net/jdk/pull/4787 From darcy at openjdk.java.net Sun Jul 18 20:47:10 2021 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 18 Jul 2021 20:47:10 GMT Subject: RFR: 8269689: Update --release 17 symbol information for JDK 17 build 31 Message-ID: Usual kind of updates for the symbol information in JDK 18 to reflect changes in the JDK 17 API. Bug fixes with API changes since JDK 17 b28 include JDK-8266313, JDK-8268972, and JDK-8266269. ------------- Commit messages: - 8269689: Update --release 17 symbol information for JDK 17 build 31 Changes: https://git.openjdk.java.net/jdk/pull/4820/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4820&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269689 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/4820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4820/head:pull/4820 PR: https://git.openjdk.java.net/jdk/pull/4820 From jlahoda at openjdk.java.net Mon Jul 19 07:27:53 2021 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Mon, 19 Jul 2021 07:27:53 GMT Subject: RFR: 8269689: Update --release 17 symbol information for JDK 17 build 31 In-Reply-To: References: Message-ID: On Sun, 18 Jul 2021 19:33:20 GMT, Joe Darcy wrote: > Usual kind of updates for the symbol information in JDK 18 to reflect changes in the JDK 17 API. Bug fixes with API changes since JDK 17 b28 include JDK-8266313, JDK-8268972, and JDK-8266269. Looks good, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4820 From mbaesken at openjdk.java.net Thu Jul 22 13:50:12 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Thu, 22 Jul 2021 13:50:12 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h Message-ID: Please review the following change. On SUSE Linux 15 configure was running into this error, because of a missing X11 header : checking for X11/extensions/Xrandr.h... no configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). I wondered about the missing package help output, we should display some hint what packages are missing. In help.m4, PKGHANDLER was detected as /usr/bin/zypper . However only the exact string zypper is checked, this should be relaxed. Afterwards, the package - help was working nicely : checking for X11/extensions/Xrandr.h... no configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). You might be able to fix this by running 'sudo zypper install libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel'. ------------- Commit messages: - JDK-8271142 Changes: https://git.openjdk.java.net/jdk/pull/4873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4873&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271142 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/4873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4873/head:pull/4873 PR: https://git.openjdk.java.net/jdk/pull/4873 From sgehwolf at openjdk.java.net Thu Jul 22 17:18:24 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 22 Jul 2021 17:18:24 GMT Subject: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info Message-ID: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> Hi! Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose to remove this hunk. Testing: Inspecting of the log files and seeing that `-g` switch is there. Run the reproducer test on the resulting static libraries. Thoughts? ------------- Commit messages: - 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info Changes: https://git.openjdk.java.net/jdk/pull/4876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4876&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271148 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4876/head:pull/4876 PR: https://git.openjdk.java.net/jdk/pull/4876 From mikael at openjdk.java.net Thu Jul 22 17:41:01 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 22 Jul 2021 17:41:01 GMT Subject: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info In-Reply-To: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> References: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> Message-ID: <2rHAsRv50O1aZScNRQFxsVy-eNIYAifUD_B3X5p7szs=.0007d8f0-e44d-4500-906e-096f82fe8f3b@github.com> On Thu, 22 Jul 2021 16:43:26 GMT, Severin Gehwolf wrote: > Hi! > > Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose to remove this hunk. > > Testing: Inspecting of the log files and seeing that `-g` switch is there. Run the reproducer test on the resulting static libraries. > > Thoughts? If I understand things correctly (and I may well be misunderstanding something), with this change the debug symbols are included in release versions of the static libraries when --with-native-debug-symbols=external is specified. That's a significant change - people may be depending on debug symbols *not* being included in the resulting release binaries. Doesn't --with-native-debug-symbols=none turn off debug symbols completely for all native code? What if one wants external debug symbols for other (non-static) libraries? ------------- PR: https://git.openjdk.java.net/jdk/pull/4876 From sgehwolf at openjdk.java.net Thu Jul 22 18:13:21 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 22 Jul 2021 18:13:21 GMT Subject: RFR: 8271148: static-libs-image target --with-native-debug-symbols=external doesn't produce debug info In-Reply-To: <2rHAsRv50O1aZScNRQFxsVy-eNIYAifUD_B3X5p7szs=.0007d8f0-e44d-4500-906e-096f82fe8f3b@github.com> References: <-WksWpFVEMR7cYkJViBGXJwLNsN8z3VeRBenp1p0Na8=.45e59698-96af-4223-a4d3-786606ea2d24@github.com> <2rHAsRv50O1aZScNRQFxsVy-eNIYAifUD_B3X5p7szs=.0007d8f0-e44d-4500-906e-096f82fe8f3b@github.com> Message-ID: <_fRQ5wNyoEK1DRlDl-eyqQVWY4VZoxph4t5jPU2dMxk=.7fff9e29-f85b-403d-b652-8283ab4d53dc@github.com> On Thu, 22 Jul 2021 17:38:28 GMT, Mikael Vidstedt wrote: >> Hi! >> >> Please review this tiny patch which removes the special casing of `--with-native-debug-symbols=external` for the static libs build. I don't see why this is needed. If no debug symbols are wanted `--with-native-debug-symbols=none` can be used to achieve the same effect. Therefore, I propose to remove this hunk. >> >> Testing: Inspecting of the log files and seeing that `-g` switch is there. Run the reproducer test on the resulting static libraries. >> >> Thoughts? > > If I understand things correctly (and I may well be misunderstanding something), with this change the debug symbols are included in release versions of the static libraries when --with-native-debug-symbols=external is specified. That's a significant change - people may be depending on debug symbols *not* being included in the resulting release binaries. > > Doesn't --with-native-debug-symbols=none turn off debug symbols completely for all native code? What if one wants external debug symbols for other (non-static) libraries? @vidmik Yes, correct. It's equally incorrect to **not** produce any debuginfo for `--with-native-debug-symbols=external`, no? With this change we have a situation where the external case for static libraries would have them include like the 'internal' case does. What's missing is the stripping part of `*.a` files, which if desired can get added to this patch too (for Linux). But to me this special casing, is not very intuitive either. Thoughts? > Doesn't --with-native-debug-symbols=none turn off debug symbols completely for all native code? What if one wants external debug symbols for other (non-static) libraries? Yes. Are you suggesting that somebody is relying on these exact semantics? Configure **once** with `--with-native-debug-symbols=external` and expect static libs to have *no* debuginfo (neither inline nor in an external file) while shared bits should have them in external files? That use case would still be possible by using two configurations. One with `--with-native-debug-symbols=external` and one with `--with-native-debug-symbols=none` and building only the needed targets each. ------------- PR: https://git.openjdk.java.net/jdk/pull/4876 From mseledtsov at openjdk.java.net Thu Jul 22 19:44:20 2021 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Thu, 22 Jul 2021 19:44:20 GMT Subject: [jdk17] RFR: 8269037: jsig/Testjsig.java doesn't have to be restricted to linux only In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 11:08:21 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this small patch that enables `runtime/jsig/Testjsig.java` test and compilation of its native library on all platforms but windows? > from JBS: >> `runtime/jsig/Testjsig.java` test currently `@requires (os.family == "linux")` and `test/hotspot/jtreg/runtime/jsig/libTestJNI.c` compilation is resticted to linux only, howere there seems to be nothing in the test code that prevents it from execution on a system that supports POSIX. > > testing: `runtime/jsig/Testjsig.java` on `{linux,windows,macosx}-x64` > > > Thanks, > -- Igor Looks good to me ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk17/pull/105 From duke at openjdk.java.net Thu Jul 22 20:03:08 2021 From: duke at openjdk.java.net (duke) Date: Thu, 22 Jul 2021 20:03:08 GMT Subject: Withdrawn: 8267312: Resolve should use generated diagnostic factories In-Reply-To: References: Message-ID: On Tue, 18 May 2021 11:07:18 GMT, Maurizio Cimadamore wrote: > This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g. > > > # 0: message segment > compiler.err.prob.found.req=... > # 0: message segment > compiler.misc.prob.found.req=... > # 0: message segment, 1: type, 2: type > compiler.warn.prob.found.req=... > > > To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise. > > This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code: > > > /** > * compiler.err.prob.found.req=\ > * incompatible types: {0} > */ > public static Error ProbFoundReq(Fragment arg0) { > return new Error("compiler", "prob.found.req", arg0) { > public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) { > return switch (kind) { > case ERROR -> this; > case WARNING -> throw new AssertionError("Unsupported kind: " + kind); > case FRAGMENT -> Fragments.ProbFoundReq(arg0); > case NOTE -> throw new AssertionError("Unsupported kind: " + kind); > }; > } > }; > } > > > As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload. > > With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories. > > The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/4089 From clanger at openjdk.java.net Fri Jul 23 08:15:05 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 23 Jul 2021 08:15:05 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h In-Reply-To: References: Message-ID: On Thu, 22 Jul 2021 13:42:09 GMT, Matthias Baesken wrote: > Please review the following change. > On SUSE Linux 15 configure was running into this error, because of a missing X11 header : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > > I wondered about the missing package help output, we should display some hint what packages are missing. > In help.m4, PKGHANDLER was detected as /usr/bin/zypper . > However only the exact string zypper is checked, this should be relaxed. > Afterwards, the package - help was working nicely : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > You might be able to fix this by running 'sudo zypper install libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel'. Makes sense to me. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4873 From mbaesken at openjdk.java.net Fri Jul 23 08:22:07 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 23 Jul 2021 08:22:07 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 08:12:21 GMT, Christoph Langer wrote: > Makes sense to me. Hi Christoph, thanks for looking into it. Should we do the same for the other package managers in the case statement (like yum, apt-get) as well ? I only observed it on SLES15 (where zypper was detected) but it might be also an issue on the others. Btw should I better use *zypper because I think it will always the suffix of the string? ------------- PR: https://git.openjdk.java.net/jdk/pull/4873 From clanger at openjdk.java.net Fri Jul 23 08:33:06 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 23 Jul 2021 08:33:06 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 08:18:48 GMT, Matthias Baesken wrote: > > Makes sense to me. > > Hi Christoph, thanks for looking into it. Should we do the same for the other package managers in the case statement (like yum, apt-get) as well ? I only observed it on SLES15 (where zypper was detected) but it might be also an issue on the others. > Btw should I better use *zypper because I think it will always the suffix of the string? Using just *zypper probably makes sense. For the other package managers it could also make sense to relax the check. I guess you should check it on relevant systems... ------------- PR: https://git.openjdk.java.net/jdk/pull/4873 From mbaesken at openjdk.java.net Fri Jul 23 14:08:29 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 23 Jul 2021 14:08:29 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h [v2] In-Reply-To: References: Message-ID: <5SQ91rEoXA7484PQoQP-AcB0XI4Az1_PZAi9k13xsj0=.bb670b4b-e3cb-4b4b-8520-38379e7fcc52@github.com> > Please review the following change. > On SUSE Linux 15 configure was running into this error, because of a missing X11 header : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > > I wondered about the missing package help output, we should display some hint what packages are missing. > In help.m4, PKGHANDLER was detected as /usr/bin/zypper . > However only the exact string zypper is checked, this should be relaxed. > Afterwards, the package - help was working nicely : > > checking for X11/extensions/Xrandr.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). > You might be able to fix this by running 'sudo zypper install libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel'. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Deal with other package handler tools ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/4873/files - new: https://git.openjdk.java.net/jdk/pull/4873/files/56269b5f..aef78749 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4873&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4873&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/4873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4873/head:pull/4873 PR: https://git.openjdk.java.net/jdk/pull/4873 From clanger at openjdk.java.net Fri Jul 23 14:08:30 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Fri, 23 Jul 2021 14:08:30 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h [v2] In-Reply-To: <5SQ91rEoXA7484PQoQP-AcB0XI4Az1_PZAi9k13xsj0=.bb670b4b-e3cb-4b4b-8520-38379e7fcc52@github.com> References: <5SQ91rEoXA7484PQoQP-AcB0XI4Az1_PZAi9k13xsj0=.bb670b4b-e3cb-4b4b-8520-38379e7fcc52@github.com> Message-ID: On Fri, 23 Jul 2021 14:04:35 GMT, Matthias Baesken wrote: >> Please review the following change. >> On SUSE Linux 15 configure was running into this error, because of a missing X11 header : >> >> checking for X11/extensions/Xrandr.h... no >> configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). >> >> I wondered about the missing package help output, we should display some hint what packages are missing. >> In help.m4, PKGHANDLER was detected as /usr/bin/zypper . >> However only the exact string zypper is checked, this should be relaxed. >> Afterwards, the package - help was working nicely : >> >> checking for X11/extensions/Xrandr.h... no >> configure: error: Could not find all X11 headers (shape.h Xrender.h Xrandr.h XTest.h Intrinsic.h). >> You might be able to fix this by running 'sudo zypper install libX11-devel libXext-devel libXrender-devel libXrandr-devel libXtst-devel libXt-devel libXi-devel'. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Deal with other package handler tools Looks good. ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4873 From mbaesken at openjdk.java.net Fri Jul 23 14:08:30 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Fri, 23 Jul 2021 14:08:30 GMT Subject: RFR: JDK-8271142: package help is not displayed for missing X11/extensions/Xrandr.h [v2] In-Reply-To: References: Message-ID: On Fri, 23 Jul 2021 08:30:28 GMT, Christoph Langer wrote: > > Hi Christoph, thanks for looking into it. Should we do the same for the other package managers in the case statement (like yum, apt-get) as well ? I only observed it on SLES15 (where zypper was detected) but it might be also an issue on the others. > > Btw should I better use *zypper because I think it will always the suffix of the string? > > Using just *zypper probably makes sense. For the other package managers it could also make sense to relax the check. I guess you should check it on relevant systems... Checked on RHEL and we have the same issue there too. before : configure: error: Could not find cups! configure exiting with result code 1 after adding my fix : configure: error: Could not find cups! You might be able to fix this by running 'sudo yum install cups-devel'. configure exiting with result code 1 So yes, the other distros/pkg handlers had the same issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/4873 From shade at openjdk.java.net Mon Jul 26 08:00:05 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Jul 2021 08:00:05 GMT Subject: RFR: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. Looks like a clean removal to me. Approving so this can be backported to JDK Updates that would be after the cert expiry date. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4851 From mullan at openjdk.java.net Mon Jul 26 19:01:31 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Mon, 26 Jul 2021 19:01:31 GMT Subject: RFR: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/4851 From rhalade at openjdk.java.net Thu Jul 29 00:25:31 2021 From: rhalade at openjdk.java.net (Rajan Halade) Date: Thu, 29 Jul 2021 00:25:31 GMT Subject: Integrated: 8225082: Remove IdenTrust certificate that is expiring in September 2021 In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 02:02:06 GMT, Rajan Halade wrote: > This CA had no code signing certificates issued so it is safe to remove it from cacerts truststore. This pull request has now been integrated. Changeset: 2ec45dc2 Author: Rajan Halade URL: https://git.openjdk.java.net/jdk/commit/2ec45dc2dd3a6bcb4f68ee7cde5858d63614305a Stats: 34 lines in 2 files changed: 0 ins; 31 del; 3 mod 8225082: Remove IdenTrust certificate that is expiring in September 2021 Reviewed-by: shade, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/4851 From rriggs at openjdk.java.net Thu Jul 29 16:44:55 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 16:44:55 GMT Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Improve the clarity of comments in the ObjectInputFilter FilterInThread example. ------------- Commit messages: - 8271489: (doc) Clarify Filter Factory example - 8270398: Enhance canonicalization - 8270404: Better canonicalization - Merge - Merge - 8263531: Remove unused buffer int - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print" - 8269763: The JEditorPane is blank after JDK-8265167 - 8265580: Enhanced style for RTF kit - 8265574: Improve handling of sheets - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561 Changes: https://git.openjdk.java.net/jdk17/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271489 Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod Patch: https://git.openjdk.java.net/jdk17/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk17/pull/292 From rriggs at openjdk.java.net Thu Jul 29 17:46:36 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 29 Jul 2021 17:46:36 GMT Subject: [jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com> Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com> On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs wrote: > Improve the clarity of comments in the ObjectInputFilter FilterInThread example. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk17/pull/292 From svijayasekar at openjdk.java.net Fri Jul 30 13:08:49 2021 From: svijayasekar at openjdk.java.net (Saravana Kumar Vijayasekaran) Date: Fri, 30 Jul 2021 13:08:49 GMT Subject: [jdk17] RFR: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) Message-ID: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) ------------- Commit messages: - 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) Changes: https://git.openjdk.java.net/jdk17/pull/297/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=297&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271150 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk17/pull/297.diff Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/297/head:pull/297 PR: https://git.openjdk.java.net/jdk17/pull/297 From iris at openjdk.java.net Fri Jul 30 17:44:33 2021 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 30 Jul 2021 17:44:33 GMT Subject: [jdk17] RFR: 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) In-Reply-To: References: Message-ID: On Fri, 30 Jul 2021 06:47:07 GMT, Saravana Kumar Vijayasekaran wrote: > 8271150: Remove EA from JDK 17 version string starting with Initial RC promotion on Aug 5, 2021(B34) Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk17/pull/297