From kevinw at openjdk.org  Thu Dec  1 12:39:05 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 1 Dec 2022 12:39:05 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <cPAGHfSbfQ3MEuJu3L9qrXdYF9uyd4AclJzosBRcc_Y=.df840a44-f308-4bed-93f2-8fdb780f1b5f@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

Added release-note in a subtask for the issue.

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

PR: https://git.openjdk.org/jdk/pull/11430

From dfuchs at openjdk.org  Thu Dec  1 16:05:30 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Dec 2022 16:05:30 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <FMiAnY0yrd2zmv5J-alpL3bhlSPwHy8SO3z2axgCVdY=.d31c9693-31c0-4742-bc5a-ffe671a8c31e@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11430

From ihse at openjdk.org  Fri Dec  2 16:54:09 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:54:09 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
Message-ID: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>

According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.

We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").

After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)

Doing so has a dual benefit:

1) It makes it clear to everyone reading the code that there is a trailing space and it is intended

2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.

Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

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

Commit messages:
 - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code

Changes: https://git.openjdk.org/jdk/pull/11490/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298046
  Stats: 28 lines in 16 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/11490.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11490/head:pull/11490

PR: https://git.openjdk.org/jdk/pull/11490

From ihse at openjdk.org  Fri Dec  2 16:54:11 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 16:54:11 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <UInZjoYKPw29_SmIzDkKdYn-qP3Yqb837vkxozDhC7Y=.7a9f5c64-36eb-4258-9dff-d7e99dfb169d@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

**A note to reviewers:**

This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences.

In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed.

I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: 
If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR.

But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you.

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

PR: https://git.openjdk.org/jdk/pull/11490

From ihse at openjdk.org  Fri Dec  2 17:12:37 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:37 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
Message-ID: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>

On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
>> 
>> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
>> 
>> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Remove check for .properties from jcheck"
>    
>    This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2.
>  - Change trailing space and tab in values to unicode encoding

This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:

[JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.

[JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:12:39 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:12:39 GMT
Subject: jmx-dev Withdrawn: 8295729: Add jcheck whitespace checking for
 properties files
In-Reply-To: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
Message-ID: <FucejIc47XdfLlKe8MOVxYBnv1k7GvnH1TgHiinx9ak=.b06a548a-3575-4456-8df4-f8804114105b@github.com>

On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes.
> 
> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible).
> 
> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10792

From ihse at openjdk.org  Fri Dec  2 17:14:23 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 17:14:23 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files
Message-ID: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>

[JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.

To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).

That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.

When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.

The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

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

Commit messages:
 - 8298047: Remove all non-significant trailing whitespace from properties files

Changes: https://git.openjdk.org/jdk/pull/11491/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298047
  Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod
  Patch: https://git.openjdk.org/jdk/pull/11491.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491

PR: https://git.openjdk.org/jdk/pull/11491

From angorya at openjdk.org  Fri Dec  2 17:15:19 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 2 Dec 2022 17:15:19 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>

On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> and instead I have split up this work in five different bugs

would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

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

PR: https://git.openjdk.org/jdk/pull/10792

From mullan at openjdk.org  Fri Dec  2 19:31:10 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 2 Dec 2022 19:31:10 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <gU6CgqxpnEwUCk-fZqLA73QpRWYcsQtjfK6Omn4yJKQ=.b04afb09-90f3-4ea1-a873-f609f01b4734@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11430

From rriggs at openjdk.org  Fri Dec  2 21:02:17 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 2 Dec 2022 21:02:17 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <dF0w6kd86J2q0wZ4hkble0vcvxm_gutG994nSoLwQlg=.22954ccc-cc79-47f3-8010-ecd177a1cbc6@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11430

From cjplummer at openjdk.org  Fri Dec  2 21:28:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Dec 2022 21:28:23 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
Message-ID: <anXdaiNVIHXjLYvfuEhGAtL9fOUR1mjPsW_FXGpNvGk=.99608bfe-6540-473f-8168-2b05c3223941@github.com>

On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.

Changes requested by cjplummer (Reviewer).

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 27:

> 25: 
> 26: ONE_DAY=\ 1 Tag
> 27: ONE_HOUR=\ 1 Stunde\u0020

Suggestion:

ONE_HOUR=\ 1 Stunde

src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174:

> 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U)
> 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5
> 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:\u0020

Suggestion:

MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:

src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties line 37:

> 35: raw.description = Startet das Ziel mit einer vom Benutzer angegebenen Befehlszeile und wird daran angeh\u00E4ngt
> 36: sun.home = Home-Verzeichnis des SDK oder der Laufzeitumgebung, die zum Starten der Anwendung verwendet wird
> 37: sun.home.label = Home\u0020

Suggestion:

sun.home.label = Home

src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties line 51:

> 49: generic_attaching.address = Adresse zum Anh\u00E4ngen f\u00FCr VM-Verbindungen
> 50: generic_attaching.address.label = Adresse
> 51: generic_attaching.timeout = Timeout beim Warten auf das Anh\u00E4ngen\u0020

Suggestion:

generic_attaching.timeout = Timeout beim Warten auf das Anh\u00E4ngen

src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties line 37:

> 35: raw.description = \u30E6\u30FC\u30B6\u30FC\u304C\u6307\u5B9A\u3057\u305F\u30B3\u30DE\u30F3\u30C9\u30E9\u30A4\u30F3\u3092\u4F7F\u7528\u3057\u3066\u30BF\u30FC\u30B2\u30C3\u30C8\u3092\u8D77\u52D5\u3057\u3001\u63A5\u7D9A\u3057\u307E\u3059
> 36: sun.home = SDK\u306E\u30DB\u30FC\u30E0\u30FB\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA\u307E\u305F\u306F\u3001\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u8D77\u52D5\u306B\u4F7F\u7528\u3055\u308C\u308B\u5B9F\u884C\u74B0\u5883
> 37: sun.home.label = \u30DB\u30FC\u30E0\u0020

Suggestion:

sun.home.label = \u30DB\u30FC\u30E0

src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties line 51:

> 49: generic_attaching.address = VM\u306B\u63A5\u7D9A\u3059\u308B\u30A2\u30C9\u30EC\u30B9
> 50: generic_attaching.address.label = \u30A2\u30C9\u30EC\u30B9
> 51: generic_attaching.timeout = \u63A5\u7D9A\u3092\u5F85\u3064\u9593\u306E\u30BF\u30A4\u30E0\u30A2\u30A6\u30C8\u0020

Suggestion:

generic_attaching.timeout = \u63A5\u7D9A\u3092\u5F85\u3064\u9593\u306E\u30BF\u30A4\u30E0\u30A2\u30A6\u30C8

src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties line 37:

> 35: raw.description = \u4F7F\u7528\u7528\u6237\u6307\u5B9A\u7684\u547D\u4EE4\u884C\u542F\u52A8\u76EE\u6807\u5E76\u9644\u52A0\u5230\u8BE5\u76EE\u6807
> 36: sun.home = \u7528\u4E8E\u542F\u52A8\u5E94\u7528\u7A0B\u5E8F\u7684 SDK \u6216\u8FD0\u884C\u65F6\u73AF\u5883\u7684\u4E3B\u76EE\u5F55
> 37: sun.home.label = \u4E3B\u76EE\u5F55\u0020

Suggestion:

sun.home.label = \u4E3B\u76EE\u5F55

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Exception thrown by the agent\u0020

Suggestion:

agent.err.exception                = Exception thrown by the agent

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Management agent class not found
> 38: agent.err.agentclass.failed        = Management agent class failed\u0020

Suggestion:

agent.err.agentclass.failed        = Management agent class failed

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties line 27:

> 25: 
> 26: agent.err.error			   = Fehler
> 27: agent.err.exception                = Ausnahme von Agent ausgel\u00F6st\u0020

Suggestion:

agent.err.exception                = Ausnahme von Agent ausgel\u00F6st

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties line 27:

> 25: 
> 26: agent.err.error			   = Error
> 27: agent.err.exception                = Excepci\u00F3n devuelta por el agente\u0020

Suggestion:

agent.err.exception                = Excepci\u00F3n devuelta por el agente

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Clase de agente de gesti\u00F3n no encontrada
> 38: agent.err.agentclass.failed        = Fallo de clase de agente de gesti\u00F3n\u0020

Suggestion:

agent.err.agentclass.failed        = Fallo de clase de agente de gesti\u00F3n

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties line 27:

> 25: 
> 26: agent.err.error			   = Erreur
> 27: agent.err.exception                = Exception envoy\u00E9e par l'agent\u0020

Suggestion:

agent.err.exception                = Exception envoy\u00E9e par l'agent

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Classe d'agents de gestion introuvable
> 38: agent.err.agentclass.failed        = Echec de la classe d'agents de gestion\u0020

Suggestion:

agent.err.agentclass.failed        = Echec de la classe d'agents de gestion

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties line 27:

> 25: 
> 26: agent.err.error			   = Errore
> 27: agent.err.exception                = Eccezione dell'agente\u0020

Suggestion:

agent.err.exception                = Eccezione dell'agente

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Classe agente gestione non trovata
> 38: agent.err.agentclass.failed        = Errore classe agente gestione\u0020

Suggestion:

agent.err.agentclass.failed        = Errore classe agente gestione

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties line 27:

> 25: 
> 26: agent.err.error			   = \u30A8\u30E9\u30FC
> 27: agent.err.exception                = \u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u304C\u4F8B\u5916\u3092\u30B9\u30ED\u30FC\u3057\u307E\u3057\u305F\u0020

Suggestion:

agent.err.exception                = \u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u304C\u4F8B\u5916\u3092\u30B9\u30ED\u30FC\u3057\u307E\u3057\u305F

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u898B\u3064\u304B\u308A\u307E\u305B\u3093
> 38: agent.err.agentclass.failed        = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u5931\u6557\u3057\u307E\u3057\u305F\u0020

Suggestion:

agent.err.agentclass.failed        = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u5931\u6557\u3057\u307E\u3057\u305F

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27:

> 25: 
> 26: agent.err.error			   = \uC624\uB958
> 27: agent.err.exception                = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.\u0020

Suggestion:

agent.err.exception                = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uCC3E\uC744 \uC218 \uC5C6\uC2B5\uB2C8\uB2E4.
> 38: agent.err.agentclass.failed        = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.\u0020

Suggestion:

agent.err.agentclass.failed        = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties line 27:

> 25: 
> 26: agent.err.error			   = Erro
> 27: agent.err.exception                = Exce\u00E7\u00E3o gerada pelo agente\u0020

Suggestion:

agent.err.exception                = Exce\u00E7\u00E3o gerada pelo agente

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Classe do agente de gerenciamento n\u00E3o encontrada
> 38: agent.err.agentclass.failed        = Falha na classe do agente de gerenciamento\u0020

Suggestion:

agent.err.agentclass.failed        = Falha na classe do agente de gerenciamento

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties line 27:

> 25: 
> 26: agent.err.error			   = Fel
> 27: agent.err.exception                = Agenten orsakade ett undantag\u0020

Suggestion:

agent.err.exception                = Agenten orsakade ett undantag

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = Administrationsagentklassen hittades inte
> 38: agent.err.agentclass.failed        = Administrationsagentklassen utf\u00F6rdes inte\u0020

Suggestion:

agent.err.agentclass.failed        = Administrationsagentklassen utf\u00F6rdes inte

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = \u627E\u4E0D\u5230\u7BA1\u7406\u4EE3\u7406\u7C7B
> 38: agent.err.agentclass.failed        = \u7BA1\u7406\u4EE3\u7406\u7C7B\u5931\u8D25\u0020

Suggestion:

agent.err.agentclass.failed        = \u7BA1\u7406\u4EE3\u7406\u7C7B\u5931\u8D25

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties line 67:

> 65: agent.err.invalid.option	   = \u6307\u5B9A\u7684\u9009\u9879\u65E0\u6548
> 66: 
> 67: jmxremote.ConnectorBootstrap.starting = \u6B63\u5728\u542F\u52A8 JMX \u8FDE\u63A5\u5668\u670D\u52A1\u5668:\u0020

Suggestion:

jmxremote.ConnectorBootstrap.starting = \u6B63\u5728\u542F\u52A8 JMX \u8FDE\u63A5\u5668\u670D\u52A1\u5668:

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties line 27:

> 25: 
> 26: agent.err.error			   = \u932F\u8AA4
> 27: agent.err.exception                = \u4EE3\u7406\u7A0B\u5F0F\u767C\u751F\u7570\u5E38\u0020

Suggestion:

agent.err.exception                = \u4EE3\u7406\u7A0B\u5F0F\u767C\u751F\u7570\u5E38

src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties line 38:

> 36: 
> 37: agent.err.agentclass.notfound      = \u627E\u4E0D\u5230\u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225
> 38: agent.err.agentclass.failed        = \u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225\u5931\u6557\u0020

Suggestion:

agent.err.agentclass.failed        = \u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225\u5931\u6557

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

PR: https://git.openjdk.org/jdk/pull/11490

From cjplummer at openjdk.org  Fri Dec  2 21:28:23 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 2 Dec 2022 21:28:23 GMT
Subject: jmx-dev RFR: 8298046: Fix hidden but significant trailing
 whitespace in properties files for serviceability code
In-Reply-To: <anXdaiNVIHXjLYvfuEhGAtL9fOUR1mjPsW_FXGpNvGk=.99608bfe-6540-473f-8168-2b05c3223941@github.com>
References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com>
 <anXdaiNVIHXjLYvfuEhGAtL9fOUR1mjPsW_FXGpNvGk=.99608bfe-6540-473f-8168-2b05c3223941@github.com>
Message-ID: <UmOG__SMSr-L4aNQ1h6bXzRcHaa8Vt5nAyENpdb8UGw=.11aaed5c-f92a-49ec-9cd6-eea620d9c9d4@github.com>

On Fri, 2 Dec 2022 21:03:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
>> 
>> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
>> 
>> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
>> 
>> Doing so has a dual benefit:
>> 
>> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
>> 
>> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
>> 
>> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team.
>
> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27:
> 
>> 25: 
>> 26: agent.err.error			   = \uC624\uB958
>> 27: agent.err.exception                = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.\u0020
> 
> Suggestion:
> 
> agent.err.exception                = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.

The pre-exiting period at the end also seems like a bug, but I'm not sure. I don't see it in the other locales.

> src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 38:
> 
>> 36: 
>> 37: agent.err.agentclass.notfound      = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uCC3E\uC744 \uC218 \uC5C6\uC2B5\uB2C8\uB2E4.
>> 38: agent.err.agentclass.failed        = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.\u0020
> 
> Suggestion:
> 
> agent.err.agentclass.failed        = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.

...and another extra period at the end that I'm unsure of.

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

PR: https://git.openjdk.org/jdk/pull/11490

From ihse at openjdk.org  Fri Dec  2 23:06:08 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 2 Dec 2022 23:06:08 GMT
Subject: jmx-dev RFR: 8295729: Add jcheck whitespace checking for
 properties files [v3]
In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
References: <nUcyMLQqktyxHgKYhpjitMYsI4IzEw4tZqFe0L6ioH4=.56ee2f1e-48b0-41f6-a852-cbe6f99edaeb@github.com>
 <zIAGVqLBXo50aa5WRbe56xpkKVEyHv0FEk4gwRXlpXg=.55305d94-5232-4a29-beea-31f54b52626c@github.com>
 <Cwps2k2ip4t3Jr5Joqk8hKXxuweY8V71hiAzZW5hto4=.8da555f4-12ef-4e10-b656-093a834e0d5f@github.com>
 <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com>
Message-ID: <BJDInfZQ8pfjgoiYRHsRTcw2dxBWSu4ZcsNC0wktKPM=.9fef5722-e842-4119-a380-46b5dd3bbc02@github.com>

On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs:
>> 
>> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit.
>> 
>> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team.
>
>> and instead I have split up this work in five different bugs
> 
> would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource?

@andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting.

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

PR: https://git.openjdk.org/jdk/pull/10792

From serb at openjdk.org  Mon Dec  5 06:10:04 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 5 Dec 2022 06:10:04 GMT
Subject: jmx-dev RFR: 8298047: Remove all non-significant trailing
 whitespace from properties files
In-Reply-To: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
References: <cw3wd4aHpDempybHLarJpHnWQ2S6eLDyj8lHmeJ-7n4=.22f4f70b-1bdb-45a8-b993-67eb3ab3e1db@github.com>
Message-ID: <WPo83xTHqjvUb3Gn342Yy6RUZUjWaFk5kLVV5oJkaoo=.9f954462-1def-40fd-a38a-c74533cee090@github.com>

On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files.
> 
> To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046).
> 
> That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns.
> 
> When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well.
> 
> The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by  running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`.

The client changes look fine.

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

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11491

From alanb at openjdk.org  Mon Dec  5 07:51:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Dec 2022 07:51:23 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <uZVOXe75Py1Cx8h_uosyCiUCw1Wsz9ze0sdsvvX3Acs=.74302942-82ca-4d86-a5c8-1ce62f7e7d50@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11430

From kevinw at openjdk.org  Mon Dec  5 09:20:31 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 5 Dec 2022 09:20:31 GMT
Subject: jmx-dev RFR: 8297794: Deprecate JMX Management Applets for
 Removal [v4]
In-Reply-To: <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
 <zvCGsvRm9viurR0SArmAefcta0gT62sP9HUZCa31-08=.16c77894-c174-4bc9-bbc4-b01c72c99b2b@github.com>
Message-ID: <a4VnCdLTmqt8NpFJz251QVLV04iknP-9X6oaVKTNgvk=.9e3756f1-65b2-4a99-b538-b80f801d78cb@github.com>

On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
>> 
>> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
>> 
>> More details in bug, and CSR JDK-8297795
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unnecessary Suppression nit

Thanks for all the reviews!

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

PR: https://git.openjdk.org/jdk/pull/11430

From kevinw at openjdk.org  Mon Dec  5 09:30:55 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 5 Dec 2022 09:30:55 GMT
Subject: jmx-dev Integrated: 8297794: Deprecate JMX Management Applets for
 Removal
In-Reply-To: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
References: <Ji8low12YtN5iTMjtD6MZPudtgOD8QvtBmM4eqHSY5o=.f384446e-574c-48c3-ab4d-5a719ec0a528@github.com>
Message-ID: <CjSBDmLVzUrDpeKLTKlrjpyq3ho7qAzMNyzQTX3Y6fs=.48ea5610-cee2-4c92-99fd-ec9347a74226@github.com>

On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal.
> 
> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools.
> 
> More details in bug, and CSR JDK-8297795

This pull request has now been integrated.

Changeset: 17666fbc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17666fbcae795a01ee462651c7694b5e4af30e32
Stats:     60 lines in 19 files changed: 41 ins; 2 del; 17 mod

8297794: Deprecate JMX Management Applets for Removal

Reviewed-by: dfuchs, mullan, rriggs, alanb

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

PR: https://git.openjdk.org/jdk/pull/11430

From bhuang at openjdk.org  Mon Dec  5 20:42:05 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Mon, 5 Dec 2022 20:42:05 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process [v7]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <RvvBp3vQGu4sgtynhdd6yVveHE3xUf47MJrZwZWSCOQ=.787f2f91-fab5-4ec9-b66a-9b9098a56f90@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Reduced host input timeout to 20 minutes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/3ae1f797..c5648165

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/10825

From bhuang at openjdk.org  Wed Dec  7 17:56:25 2022
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 7 Dec 2022 17:56:25 GMT
Subject: jmx-dev RFR: JDK-8295756 Improve NonLocalRegistry Manual Test
 Process [v8]
In-Reply-To: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
References: <zimo9_4V7yIIQ80Etwuvzqy7sRZvsJw5zbaeYv6J8gM=.67e06cf4-0f42-4f2c-9081-9fd5461b7b12@github.com>
Message-ID: <Zo4vDXJQgrwa9N0aQs5CPrzxuONmixM-nogpsLogQBs=.f4067505-b186-4a7e-8679-9dde40a5a736@github.com>

> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. 
> 
> Tests include: 
> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java 
> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java 
> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Reduced host input timeout to 5 minutes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10825/files
  - new: https://git.openjdk.org/jdk/pull/10825/files/c5648165..761cf908

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/10825

From kevinw at openjdk.org  Wed Dec  7 22:01:12 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 7 Dec 2022 22:01:12 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest test
 failed: no decrease in Eden usage
Message-ID: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>

Test should not check that Eden has decreased in used size if the GCCause is "No GC".

These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.

Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

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

Commit messages:
 - 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage

Changes: https://git.openjdk.org/jdk/pull/11572/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298173
  Stats: 33 lines in 1 file changed: 8 ins; 4 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/11572.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11572/head:pull/11572

PR: https://git.openjdk.org/jdk/pull/11572

From dcubed at openjdk.org  Wed Dec  7 22:41:05 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Dec 2022 22:41:05 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <aFAVIekz2fK5dUj13gS8ov8JMo_0RwcHg4BCSMe_c1k=.0b0e7d9a-80eb-4abc-a466-cd183bea9143@github.com>

On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

The variable renaming and code clean ups were a bit distracting.
However, I'm okay with the changes to skip verification when
"No GC" is the GCCause.

What kind of testing was done?

The bug is targeted at '21'. If you plan to fix this in '20' before
the cutoff, then please change the target to '20'. If you don't
plan to fix this in '20', then you'll need to ProblemList the test
in '20' because this failure is rather noisy as we already have
6 sightings in the JDK20 CI.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11572

From cjplummer at openjdk.org  Wed Dec  7 22:51:08 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 7 Dec 2022 22:51:08 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <3uITQINIchOdjOY5Sqv4UGemtNrwwalB68sM99QlXLI=.fbfe4859-eb97-4795-9ccd-ac2278d91550@github.com>

On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11572

From dcubed at openjdk.org  Wed Dec  7 23:13:42 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 7 Dec 2022 23:13:42 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <U1PMyTTdfuHt1jPXfzR8tvwRggZKXs-t3TR5B7fP1h4=.8b767dc2-95d1-4e77-a935-70e27fcdf6f4@github.com>

On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

This bug appears to be a regression caused by the fix for:

[JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1

so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've
also retargeted the bug from '21' -> '20'.

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

PR: https://git.openjdk.org/jdk/pull/11572

From sspitsyn at openjdk.org  Thu Dec  8 01:02:41 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 8 Dec 2022 01:02:41 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com>

On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

Looks good.
Posted one nit.
Thanks,
Serguei

test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java line 94:

> 92:         numberOfGCMBeans = names.size();
> 93:         for (ObjectName n : names) {
> 94:             if(mbs.isInstanceOf(n, "javax.management.NotificationEmitter")) {

Nit: missed space in "if(".

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11572

From kevinw at openjdk.org  Thu Dec  8 11:52:14 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Dec 2022 11:52:14 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage [v2]
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <Ix4TRsa36ReNuJB_bH82cu_ryzIxD4SAiUMspEPI2g0=.3227d510-4017-4493-bce1-8463f04db5f4@github.com>

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  nit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11572/files
  - new: https://git.openjdk.org/jdk/pull/11572/files/71607383..9ef9c94d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/11572

From kevinw at openjdk.org  Thu Dec  8 11:52:14 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Dec 2022 11:52:14 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage [v2]
In-Reply-To: <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
 <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com>
Message-ID: <ajSO4i2WukhkAu2uti7sUjM4yyGfkfTBRMgI6TkqyoQ=.52df4eb5-3672-4699-803b-fdf2c269877c@github.com>

On Thu, 8 Dec 2022 00:58:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   nit
>
> test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java line 94:
> 
>> 92:         numberOfGCMBeans = names.size();
>> 93:         for (ObjectName n : names) {
>> 94:             if(mbs.isInstanceOf(n, "javax.management.NotificationEmitter")) {
> 
> Nit: missed space in "if(".

got it 8-)

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

PR: https://git.openjdk.org/jdk/pull/11572

From kevinw at openjdk.org  Thu Dec  8 11:58:44 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Dec 2022 11:58:44 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <U1PMyTTdfuHt1jPXfzR8tvwRggZKXs-t3TR5B7fP1h4=.8b767dc2-95d1-4e77-a935-70e27fcdf6f4@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
 <U1PMyTTdfuHt1jPXfzR8tvwRggZKXs-t3TR5B7fP1h4=.8b767dc2-95d1-4e77-a935-70e27fcdf6f4@github.com>
Message-ID: <sVOY_BFOEvGwGBep4G74P_6Cf6do_6zBJcA1nIZYxvQ=.e4d85b7b-4029-4f0d-a2ab-d8755fb06567@github.com>

On Wed, 7 Dec 2022 23:10:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
>> 
>> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
>> 
>> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.
>
> This bug appears to be a regression caused by the fix for:
> 
> [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1
> 
> so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've
> also retargeted the bug from '21' -> '20'.

Thanks for the reviews, thanks @dcubed-ojdk  for the pointer to the other change - this did not start failing by coincidence, there are new notifications happening.

It is hard to reproduce the failure, and they are mostly on linux aarch64, but I've seen one locally on linux x64. 
 The failures show an event where Eden size does not change: the test says that eden before size <= after size is a failure.

I cannot reproduce the problem with this change in mach5 or locally, in many runs.

Yes, the cleanup changes are distracting, but "count"?  That should be more meaningful. 8-)

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

PR: https://git.openjdk.org/jdk/pull/11572

From kevinw at openjdk.org  Thu Dec  8 12:13:06 2022
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 8 Dec 2022 12:13:06 GMT
Subject: jmx-dev Integrated: 8298173:
 GarbageCollectionNotificationContentTest test failed: no decrease in Eden
 usage
In-Reply-To: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
Message-ID: <VooeQS3yg-_MhIFLV4XWbKP3-rrnwoed3FxjHjXeRA8=.349acedb-7e0e-44bf-888e-2db15a582cba@github.com>

On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test should not check that Eden has decreased in used size if the GCCause is "No GC".
> 
> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport).  This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change.
> 
> Updated a few variable names to make it more obvious what count and number are recording, and some formatting.  The key  part of the change is at line 137 onwards.

This pull request has now been integrated.

Changeset: fbe7b007
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbe7b007383b034589e93d398706bebeb24461ee
Stats:     33 lines in 1 file changed: 8 ins; 4 del; 21 mod

8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage

Reviewed-by: dcubed, cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/11572

From dcubed at openjdk.org  Thu Dec  8 15:40:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 8 Dec 2022 15:40:02 GMT
Subject: jmx-dev RFR: 8298173: GarbageCollectionNotificationContentTest
 test failed: no decrease in Eden usage
In-Reply-To: <sVOY_BFOEvGwGBep4G74P_6Cf6do_6zBJcA1nIZYxvQ=.e4d85b7b-4029-4f0d-a2ab-d8755fb06567@github.com>
References: <xoQ2gelMIH5YrjrgRQeILNsLF7BxX7YZdluimUtfO30=.7f49f7f0-6172-478b-bbdf-64e25e58d6bf@github.com>
 <U1PMyTTdfuHt1jPXfzR8tvwRggZKXs-t3TR5B7fP1h4=.8b767dc2-95d1-4e77-a935-70e27fcdf6f4@github.com>
 <sVOY_BFOEvGwGBep4G74P_6Cf6do_6zBJcA1nIZYxvQ=.e4d85b7b-4029-4f0d-a2ab-d8755fb06567@github.com>
Message-ID: <NU7rjDZhg2cPQ0UCByDXJp1zV7W9tff9o9j1iC3QnlI=.e124190f-f775-45e8-a5a7-78ec2dc0a572@github.com>

On Thu, 8 Dec 2022 11:55:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This bug appears to be a regression caused by the fix for:
>> 
>> [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1
>> 
>> so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've
>> also retargeted the bug from '21' -> '20'.
>
> Thanks for the reviews, thanks @dcubed-ojdk  for the pointer to the other change - this did not start failing by coincidence, there are new notifications happening.
> 
> It is hard to reproduce the failure, and they are mostly on linux aarch64, but I've seen one locally on linux x64. 
>  The failures show an event where Eden size does not change: the test says that eden before size <= after size is a failure.
> 
> I cannot reproduce the problem with this change in mach5 or locally, in many runs.
> 
> Yes, the cleanup changes are distracting, but "count"?  That should be more meaningful. 8-)
> 
> Integrating now to be in jdk20.

@kevinjwalls - Thanks for getting the fix integrated into JDK20.
The CI will be less noisy today!

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

PR: https://git.openjdk.org/jdk/pull/11572

From kbarrett at openjdk.org  Thu Dec 22 02:12:47 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 22 Dec 2022 02:12:47 GMT
Subject: jmx-dev [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java
 failed "RuntimeException: assertTrue: expected true, was false"
Message-ID: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>

Please review this change to WhiteBox and some tests involving G1 concurrent GCs.

Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
concurrent GC.  Many of them follow it with a loop waiting for a concurrent
cycle to not be in progress.  A few also preceed that call with a similar
loop, since that call does nothing and returns false if a concurrent cycle is
already in progress.  Those tests typically want to ensure there was a
concurrent cycle that was started after some setup.

The failing test calls that function, asserting that it returned true, e.g. a
new concurrent cycle was started.

There are various problems with this, due to races with concurrent cycles
started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
making some of these tests unreliable in some configurations.

For example, the test failure associated with this bug intermittently arises
when running with `-Xcomp`, triggering a concurrent cycle before the explicit
request by the test, causing the explicit request to fail (because there is
already one in progress), failing the assert.  Waiting for there not to be an
in-progress cycle before the explicit request just narrows the race window.

We have a different mechanism in WhiteBox for controlling concurrent cycles,
the concurrent GC breakpoint mechanism.  By adding a counter specifically for
such cycles, we can use GC breakpoints to ensure only the concurrent cycles
the test wants are occurring, and can verify they completed successfully.

So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
avoid racing request problems and to detect aborted cycles.  Since it is no
longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
serves any purpose, having been purely a test of that removed function.

Testing:
mach5 tier1-7 - running the changed tests on a variety of platforms with a
variety of configurations.

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

Commit messages:
 - use gc breakpoints to perform conc gc

Changes: https://git.openjdk.org/jdk20/pull/71/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293824
  Stats: 288 lines in 24 files changed: 98 ins; 131 del; 59 mod
  Patch: https://git.openjdk.org/jdk20/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71

PR: https://git.openjdk.org/jdk20/pull/71

From iwalulya at openjdk.org  Thu Dec 22 16:14:48 2022
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 22 Dec 2022 16:14:48 GMT
Subject: jmx-dev [jdk20] RFR: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <KDWDqPiHkgakhFDbNdeWz5erUt1A2CBCXvk2SfwpkMw=.70bed1bf-5922-404f-8159-ee31cf1ed2bf@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/71

From kbarrett at openjdk.org  Sat Dec 24 06:51:58 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 24 Dec 2022 06:51:58 GMT
Subject: jmx-dev [jdk20] RFR: 8293824:
 gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue:
 expected true, was false"
In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com>
Message-ID: <SrUgx448r-lYaUKGZjvnNGyPIhQTeHujxNAC82j9SWY=.8d8b4d69-9d5f-4a03-9aea-5f8ee677fa49@github.com>

On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to WhiteBox and some tests involving G1 concurrent GCs.
> 
> Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a
> concurrent GC.  Many of them follow it with a loop waiting for a concurrent
> cycle to not be in progress.  A few also preceed that call with a similar
> loop, since that call does nothing and returns false if a concurrent cycle is
> already in progress.  Those tests typically want to ensure there was a
> concurrent cycle that was started after some setup.
> 
> The failing test calls that function, asserting that it returned true, e.g. a
> new concurrent cycle was started.
> 
> There are various problems with this, due to races with concurrent cycles
> started automatically, and due to possibly aborted (by full GCs) concurrent cycles,
> making some of these tests unreliable in some configurations.
> 
> For example, the test failure associated with this bug intermittently arises
> when running with `-Xcomp`, triggering a concurrent cycle before the explicit
> request by the test, causing the explicit request to fail (because there is
> already one in progress), failing the assert.  Waiting for there not to be an
> in-progress cycle before the explicit request just narrows the race window.
> 
> We have a different mechanism in WhiteBox for controlling concurrent cycles,
> the concurrent GC breakpoint mechanism.  By adding a counter specifically for
> such cycles, we can use GC breakpoints to ensure only the concurrent cycles
> the test wants are occurring, and can verify they completed successfully.
> 
> So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC
> breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to
> avoid racing request problems and to detect aborted cycles.  Since it is no
> longer used, WhiteBox.g1StartConcMarkCycle() is removed.  The test that began
> this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer
> serves any purpose, having been purely a test of that removed function.
> 
> Testing:
> mach5 tier1-7 - running the changed tests on a variety of platforms with a
> variety of configurations.

BTW, after this change `GCCause::_wb_conc_mark` appears to no longer ever be issued.  I'm planning to remove it under the rubric of JDK-8235737.

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

PR: https://git.openjdk.org/jdk20/pull/71

From mernst at openjdk.org  Tue Dec 27 14:26:39 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:39 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v3]
In-Reply-To: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
Message-ID: <G6y9-__VIQjwSKAhHqAaBz9XhPTAsANIlDIZqrlAlow=.efb3bc20-d266-4717-84ee-b970989f8e44@github.com>

> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge ../jdk-openjdk into typos-typos
 - Reinstate typos in Apache code that is copied into the JDK
 - Merge ../jdk-openjdk into typos-typos
 - Remove file that was removed upstream
 - Fix inconsistency in capitalization
 - Undo change in zlip
 - Fix typos

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

Changes: https://git.openjdk.org/jdk/pull/10029/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02
  Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/10029.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029

PR: https://git.openjdk.org/jdk/pull/10029

From mernst at openjdk.org  Tue Dec 27 14:26:40 2022
From: mernst at openjdk.org (Michael Ernst)
Date: Tue, 27 Dec 2022 14:26:40 GMT
Subject: jmx-dev RFR: 8294321: Fix typos in files under test/jdk/java,
 test/jdk/jdk, test/jdk/jni [v2]
In-Reply-To: <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
References: <Son2XWweoJeNzBalwQ4_ujZfK_jkwdh5tEozAk8QXXo=.e1ccc05f-84d7-454d-be22-5855aeed0c52@github.com>
 <JM2iW2-imTXG8KxxinxGWCXP8FwOesEjeQheWbooMoY=.2dfbad6d-e4e3-43b3-90b9-fdd7ac22e9d1@github.com>
 <gOXCJJl7JqlhdMiDjhu5kbAGieFHPelXHl_XvNG3Pyw=.881b6edb-36c1-4044-99da-18b45b28a69b@github.com>
 <o4GUMwlhtn6ng4FZjHRzZ3iqJD0dlAWKnXsufxhmbqk=.4920d482-3bba-4814-88b6-6a7e839349e2@github.com>
Message-ID: <KQM3bb5WQ1wCnIsc8lnqTrD54nkWyrhnHyk7hkSfp70=.5924492b-d7e8-4a26-bbe7-f78f0c9f9959@github.com>

On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs?  Then it can be merged, rather than wasting all the effort that went into it.
>
>> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it.
> 
> I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs.

Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes.
I have pulled master and resolved merge conflicts.  Only 11 typo fixes remain.
Could someone shepherd those into the codebase?  Thanks!

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

PR: https://git.openjdk.org/jdk/pull/10029