From ihse at openjdk.java.net  Thu Nov  4 10:51:27 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 10:51:27 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in serviceability
 code
Message-ID: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>

I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

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

Commit messages:
 - 8276628: Use blessed modifier order in serviceability code

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

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

From dholmes at openjdk.java.net  Thu Nov  4 12:23:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Nov 2021 12:23:23 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <U_K0loGNtPPxro0uV5tcd2s8TJvDoA2niwrl2wOp0RE=.6610b7a7-0d97-4172-b7be-35b2f5aba7c2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Looks fine to me.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From lmesnik at openjdk.java.net  Thu Nov  4 14:26:10 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 4 Nov 2021 14:26:10 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <eUAIYw2CAhxBKXU3qG24cChmOkmFuZBtom-XT-XRXkA=.5ac70260-2594-4230-b6e1-103bb5c260b2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by lmesnik (Reviewer).

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

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

From cjplummer at openjdk.java.net  Thu Nov  4 16:03:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 16:03:21 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Copyright updates?

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

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

From ihse at openjdk.java.net  Thu Nov  4 17:07:24 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:07:24 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code
In-Reply-To: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
Message-ID: <NX5Z8gVBGw82IJ7UtNOmZPwzD6D---Nj3uiBZQeEhqU=.8bbccacb-32bd-4bbb-9c66-a6ef20a32eda@github.com>

On Thu, 4 Nov 2021 15:59:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Copyright updates?

@plummercj That's really kind of an edge case, considering the triviality of these changes. But yes, the norm in the JDK is to update the copyright year for all changes, so you're right, I should do that.

(And we *really* ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

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

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

From ihse at openjdk.java.net  Thu Nov  4 17:36:52 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:36:52 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code [v2]
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6249/files
  - new: https://git.openjdk.java.net/jdk/pull/6249/files/cf5db105..8a5ff8a5

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

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

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

From cjplummer at openjdk.java.net  Thu Nov  4 18:08:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 18:08:11 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <-iSUoILuWhTb2AgWH-HGAsEm4Nvo8Fl6NIVaiFTY3Lo=.5ec41a0d-e7f3-4f57-b651-7c1971f48e3c@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Marked as reviewed by cjplummer (Reviewer).

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

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

From dholmes at openjdk.java.net  Fri Nov  5 00:38:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 5 Nov 2021 00:38:13 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <7jntohY4FpQYK4L1W1l8wkvamKZhSTjXqtS0CEYIJ7k=.0e5e17bf-d6e5-41dc-8ffd-e30fb4803a29@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Good catch on copyright updates @plummercj ! We always have to update when we modify a file - the one exception is changing the wording of the copyright notice itself.

Looks good.

David

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

Marked as reviewed by dholmes (Reviewer).

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

From ihse at openjdk.java.net  Fri Nov  5 12:11:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 12:11:18 GMT
Subject: jmx-dev Integrated: 8276628: Use blessed modifier order in
 serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <2SDPO7MFjKGYKDVlnVRdStd7XwlgsX3XA9PMfIGph5g=.8efd0769-4b5b-4014-b4ea-b6043f45b97f@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: 7023b3f8
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b
Stats:     284 lines in 89 files changed: 0 ins; 0 del; 284 mod

8276628: Use blessed modifier order in serviceability code

Reviewed-by: dholmes, lmesnik, cjplummer

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

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

From asarkar at openjdk.java.net  Mon Nov  8 04:20:39 2021
From: asarkar at openjdk.java.net (Anirvan Sarkar)
Date: Mon, 8 Nov 2021 04:20:39 GMT
Subject: jmx-dev RFR: 8276628: Use blessed modifier order in
 serviceability code [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <c_E3qAG1nXTRWsQtbzJRtlEfQ7QBdawM4TWIzwaR1Mo=.5d37fd57-cf4f-4193-8ecb-8be0b169b989@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

> (And we _really_ ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

OpenJFX team seems to have a copyright update script[1].
Maybe @kevinrushforth can tell if it can be retrofitted and used by OpenJDK project.

[1] : https://bugs.openjdk.java.net/browse/JDK-8214793?focusedCommentId=14233661&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14233661

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

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

From stuefe at openjdk.java.net  Mon Nov 15 07:49:44 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 15 Nov 2021 07:49:44 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes
Message-ID: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>

jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:


void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
          jstring command, dcmdArgInfo* infoArray)


but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.

Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.

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

Testing:
- manual tests with artificially induced error in one dcmd for debug, release
- GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)

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

Commit messages:
 - explicitly pass output array size and check it in hotspot

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

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

From dholmes at openjdk.java.net  Mon Nov 15 10:04:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 15 Nov 2021 10:04:39 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes
In-Reply-To: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
Message-ID: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>

On Fri, 12 Nov 2021 08:25:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
> 
> 
> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>           jstring command, dcmdArgInfo* infoArray)
> 
> 
> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
> 
> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
> 
> -------------
> 
> Testing:
> - manual tests with artificially induced error in one dcmd for debug, release
> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)

Hi Thomas,

Sorry but only half of this makes sense to me.

Cheers,
David

src/hotspot/share/services/management.cpp line 1968:

> 1966: 
> 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds,
> 1968:           dcmdInfo* infoArray, jint count))

I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ?

src/hotspot/share/services/management.cpp line 2022:

> 2020: 
> 2021: JVM_ENTRY(void, jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
> 2022:           jstring command, dcmdArgInfo* infoArray, jint count))

This one makes sense because you verify that the external expectation about the arg count matches the actual internal representation.

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

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

From stuefe at openjdk.java.net  Mon Nov 15 10:21:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 15 Nov 2021 10:21:43 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes
In-Reply-To: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
Message-ID: <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com>

On Mon, 15 Nov 2021 09:59:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
>> 
>> 
>> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>>           jstring command, dcmdArgInfo* infoArray)
>> 
>> 
>> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
>> 
>> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
>> 
>> -------------
>> 
>> Testing:
>> - manual tests with artificially induced error in one dcmd for debug, release
>> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)
>
> src/hotspot/share/services/management.cpp line 1968:
> 
>> 1966: 
>> 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds,
>> 1968:           dcmdInfo* infoArray, jint count))
> 
> I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ?

Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. 

Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part.

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

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

From sspitsyn at openjdk.java.net  Tue Nov 16 01:57:37 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 16 Nov 2021 01:57:37 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes
In-Reply-To: <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
 <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com>
Message-ID: <MP2fbaCrdj20Dj3DCFEYhzOAfpMbYuTwKy414TBN_UI=.bf4c9762-b176-40a8-92c0-3c0f7aa3ac91@github.com>

On Mon, 15 Nov 2021 10:18:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/services/management.cpp line 1968:
>> 
>>> 1966: 
>>> 1967: JVM_ENTRY(void, jmm_GetDiagnosticCommandInfo(JNIEnv *env, jobjectArray cmds,
>>> 1968:           dcmdInfo* infoArray, jint count))
>> 
>> I do not see the point of the change in this case. This doesn't check for a mismatch between an "external" and "internal" value but between two external values. If you don't trust the caller to size infoArray correctly then how can you trust them to pass in the right "count" ?
>
> Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. 
> 
> Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part.

Hi Thomas,

I kind of agree with David.
The symmetry does not help in this case as it creates a bit of confusion. :)

Thanks,
Serguei

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

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

From dholmes at openjdk.java.net  Tue Nov 16 02:15:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 16 Nov 2021 02:15:34 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes
In-Reply-To: <MP2fbaCrdj20Dj3DCFEYhzOAfpMbYuTwKy414TBN_UI=.bf4c9762-b176-40a8-92c0-3c0f7aa3ac91@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
 <6Xey3TunPhX-BUlydf9ArCSrjQ0GXG2Fb-GkOZdXuQw=.999f9ea4-55fd-4e04-b3b2-7a42ab74a809@github.com>
 <MP2fbaCrdj20Dj3DCFEYhzOAfpMbYuTwKy414TBN_UI=.bf4c9762-b176-40a8-92c0-3c0f7aa3ac91@github.com>
Message-ID: <A3j3vwvo6Vtt-iBWqCbUish3_ZxnhBMNCzkvfWAJZVQ=.d2f92ea0-e544-4d19-bb8f-e0c5f42d4f50@github.com>

On Tue, 16 Nov 2021 01:54:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Well, it warns in case of programming errors. I agree, that programming error is very unlikely since the caller has all the information he needs. And he could pass in the wrong count. 
>> 
>> Idk. Mostly I changed this interface to follow the established pattern of always passing in an explicit output buffer size. And to keep it symmetric to``jmm_GetDiagnosticCommandArgumentsInfo` and `jmm_GetGCExtAttributeInfo`. If you object, I'll remove this part.
>
> Hi Thomas,
> 
> I kind of agree with David.
> The symmetry does not help in this case as it creates a bit of confusion. :)
> 
> Thanks,
> Serguei

Thomas, please drop this part. Thanks.

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

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

From stuefe at openjdk.java.net  Tue Nov 16 06:26:08 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 16 Nov 2021 06:26:08 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes [v2]
In-Reply-To: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
Message-ID: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>

> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
> 
> 
> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>           jstring command, dcmdArgInfo* infoArray)
> 
> 
> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
> 
> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
> 
> -------------
> 
> Testing:
> - manual tests with artificially induced error in one dcmd for debug, release
> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Remove changes to GetDiagnosticCommandInfo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6363/files
  - new: https://git.openjdk.java.net/jdk/pull/6363/files/65dad518..3bdc6c89

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

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

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

From stuefe at openjdk.java.net  Tue Nov 16 06:26:11 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 16 Nov 2021 06:26:11 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes [v2]
In-Reply-To: <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <6rJhYTnn4sOE-DchxS36pIkwiSrN8WbdFyEFuoday3M=.47405cb2-9a9d-4e1c-86eb-ac76f4bbc749@github.com>
Message-ID: <SpSYEQaVNBMpHyZxH7SDgewCZVJyEg2Cegvb1-wjpHA=.5cb3c4d8-52e7-4cb6-ad40-84b7c99faeaf@github.com>

On Mon, 15 Nov 2021 10:01:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove changes to GetDiagnosticCommandInfo
>
> Hi Thomas,
> 
> Sorry but only half of this makes sense to me.
> 
> Cheers,
> David

@dholmes-ora, @sspitsyn Thanks for your reviews. I removed the changes to GetDiagnosticCommandInfo as requested.

Thanks, Thomas

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

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

From sspitsyn at openjdk.java.net  Tue Nov 16 06:40:35 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Tue, 16 Nov 2021 06:40:35 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes [v2]
In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
Message-ID: <kXUIw1ezAHjycctOAP5guB1UTKoyxlcFw7PMPaz8-yg=.7702efc2-d96e-4196-af84-e8d7f70c46d1@github.com>

On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
>> 
>> 
>> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>>           jstring command, dcmdArgInfo* infoArray)
>> 
>> 
>> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
>> 
>> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
>> 
>> -------------
>> 
>> Testing:
>> - manual tests with artificially induced error in one dcmd for debug, release
>> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes to GetDiagnosticCommandInfo

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From dholmes at openjdk.java.net  Tue Nov 16 07:40:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 16 Nov 2021 07:40:36 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes [v2]
In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
Message-ID: <-G3K5V_UAAVM6-e_hiTXRpdxpbWe0W2uSPGpifLV9d0=.7fd11fdc-319c-468b-a63b-ac18c2c3acf0@github.com>

On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
>> 
>> 
>> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>>           jstring command, dcmdArgInfo* infoArray)
>> 
>> 
>> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
>> 
>> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
>> 
>> -------------
>> 
>> Testing:
>> - manual tests with artificially induced error in one dcmd for debug, release
>> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes to GetDiagnosticCommandInfo

Thanks

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

Marked as reviewed by dholmes (Reviewer).

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

From stuefe at openjdk.java.net  Tue Nov 16 09:52:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 16 Nov 2021 09:52:42 GMT
Subject: jmx-dev RFR: JDK-8277029: JMM GetDiagnosticXXXInfo APIs should
 verify output array sizes [v2]
In-Reply-To: <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
 <7BKPwCXf1m9wKd5yOJaWg6ZyCCSvZwgZdOz7Z_tFf9U=.a506a1cf-524a-4e8a-a0fd-145766d3ef34@github.com>
Message-ID: <3OOui2hpFGXW7BvpMHVMk6MCkAOqeMzWDPF4UOmat-E=.f21f6a27-6b16-4a2a-96e0-865ef70cdf80@github.com>

On Tue, 16 Nov 2021 06:26:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
>> 
>> 
>> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>>           jstring command, dcmdArgInfo* infoArray)
>> 
>> 
>> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
>> 
>> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
>> 
>> -------------
>> 
>> Testing:
>> - manual tests with artificially induced error in one dcmd for debug, release
>> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)
>
> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove changes to GetDiagnosticCommandInfo

Thanks David and Serguey

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

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

From stuefe at openjdk.java.net  Tue Nov 16 09:52:43 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 16 Nov 2021 09:52:43 GMT
Subject: jmx-dev Integrated: JDK-8277029: JMM GetDiagnosticXXXInfo APIs
 should verify output array sizes
In-Reply-To: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
References: <THfykOI9_zZq-f1l_FnpmW2_GVtVm6LCwPwHxmormv8=.1f3f36ed-0bc1-4e2e-8ccf-eae940b98f45@github.com>
Message-ID: <6n0IFXT7fiHk1z6WyJO-sVPkwtS0re9q1dZkmnvNRRc=.71b54340-3efe-4b58-b583-80335870ee12@github.com>

On Fri, 12 Nov 2021 08:25:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> jmm_GetDiagnosticCommandArgumentsInfo and jmm_GetDiagnosticCommandInfo are used to query the hotspot about diagnostic commands. They provide output arrays for the information:
> 
> 
> void jmm_GetDiagnosticCommandArgumentsInfo(JNIEnv *env,
>           jstring command, dcmdArgInfo* infoArray)
> 
> 
> but array size is implicitly assumed to be known to both caller and callee. Caller and callee negotiate those sizes in prior steps, but things can go wrong. E.g. I recently hunted a bug where `DCmd::number_arguments()` was off - did not reflect the real number of its jcmd parameters - which led to a hidden memory overwriter.
> 
> Thankfully, JDK-8264565 rewrote the dcmd framework to deal with this particular issue (The VM I analyzed was older). Still, it would be good if we had additional safety measures here.
> 
> -------------
> 
> Testing:
> - manual tests with artificially induced error in one dcmd for debug, release
> - GHAs (which include tier1 serviceability jcmd tests which use JMX and exercise these APIs)

This pull request has now been integrated.

Changeset: b8d33a2a
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb
Stats:     9 lines in 3 files changed: 3 ins; 0 del; 6 mod

8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes

Reviewed-by: dholmes, sspitsyn

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

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

From duke at openjdk.java.net  Tue Nov 16 11:22:39 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Nov 2021 11:22:39 GMT
Subject: jmx-dev Integrated: 8274757: Cleanup unnecessary calls to
 Throwable.initCause() in java.management module
In-Reply-To: <f7aFxzQ8FM549Z42gV6GNhwWxmLzHPCzT-MjuHXdQLA=.ccd3985e-1251-4476-a73a-598fb7403bc1@github.com>
References: <f7aFxzQ8FM549Z42gV6GNhwWxmLzHPCzT-MjuHXdQLA=.ccd3985e-1251-4476-a73a-598fb7403bc1@github.com>
Message-ID: <0H6MSkm8X_gEWr3RZFuV6206SSeKyUpnhxLMwybzuQo=.8db72fee-8677-458b-954d-677ab2090c61@github.com>

On Thu, 16 Sep 2021 20:45:36 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> Pass cause exception as constructor parameter is shorter and easier to read.

This pull request has now been integrated.

Changeset: 1c45c8a0
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207
Stats:     50 lines in 10 files changed: 0 ins; 32 del; 18 mod

8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module

Reviewed-by: dfuchs, sspitsyn

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

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