From coleenp at openjdk.org  Thu Jan  2 12:37:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 12:37:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
 <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
 <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
Message-ID: <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>

On Wed, 25 Dec 2024 16:34:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> It wasn't the logic.  When I went through I didn't know if this instruction needed fixing because we loaded an unsigned short instead of an int.  So I left myself a note to look at it again that you noticed and I didn't in my final walk through.  It seems right but maybe someone with ppc knowledge can answer this.
>> 
>> 
>>     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
>
> The instruction looks still correct. We are checking the same bit of the 64 bit register as before. (Using `testbitdi` would also work.)

I changed this to testbitdi.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900836026

From mdoerr at openjdk.org  Thu Jan  2 12:55:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Jan 2025 12:55:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
 <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
 <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>
 <MT8uIXYGd9piv0ucdKYoMMaiDT_ovxFP-5olTVO8x_0=.bcc94c19-c75a-4fd6-be33-bca4e75bc491@github.com>
Message-ID: <BFtXal4fiYWTbisCegWXYTMkWf0Kn-TTQfSQeZrxByU=.819f4cf0-df56-4b53-8f10-c9b5050c09d5@github.com>

On Thu, 2 Jan 2025 12:34:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The instruction looks still correct. We are checking the same bit of the 64 bit register as before. (Using `testbitdi` would also work.)
>
> I changed this to testbitdi.

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900849068

From coleenp at openjdk.org  Thu Jan  2 12:59:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 12:59:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>
Message-ID: <XTG5K61GEgvZcGXyO5aczl07jaWjyFYeT6DRp5aJMac=.29b8719c-c3a9-47e7-b76e-3d45da536a02@github.com>

On Fri, 20 Dec 2024 21:34:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore ACC in comment.
>
> src/hotspot/share/oops/method.cpp line 1655:
> 
>> 1653:     return;
>> 1654:   }
>> 1655:   jshort flags = checked_cast<jshort>(access_flags().as_unsigned_short());
> 
> Can we cleanup the intrinsics code next, to stop using jshort for flags?

I was going to file a new issue but this is really easy to fix, so I added this fix to this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900852859

From coleenp at openjdk.org  Thu Jan  2 13:04:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:04:18 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v6]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <f3Ndp77aLf69daUZUm1bHYShhmJKJONEDywZPRY7rMY=.7c07db10-26d0-4eb7-82b0-c447ae899ed6@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Make vmIntrinsics::find_id() take u2 not jshort.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/4faf19ba..df95d447

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

  Stats: 13 lines in 3 files changed: 1 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

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

From coleenp at openjdk.org  Thu Jan  2 13:08:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:08:12 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v7]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix lhz in ppc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/df95d447..5a84b139

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

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

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

From coleenp at openjdk.org  Thu Jan  2 13:08:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:08:12 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
Message-ID: <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>

On Wed, 25 Dec 2024 16:40:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore ACC in comment.
>
> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 149:
> 
>> 147:     // _access_flags must be a 16 bit value.
>> 148:     assert(sizeof(AccessFlags) == 2, "wrong size");
>> 149:     __ lha(R11_scratch1/*access_flags*/, method_(access_flags));
> 
> Using `lhz` would be more consistent. `lha` uses sign extend instead of zero extend. Feel free to clean this up if you want. Both instructions should work.

I fixed this - it was the only one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900858739

From yasuenag at gmail.com  Thu Jan  2 13:11:35 2025
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 2 Jan 2025 22:11:35 +0900
Subject: Alternative to sadebugd
Message-ID: <44818014-55cf-4e3f-aef0-96950c8b1cd5@gmail.com>

Hi all,

sadebugd and related options in jhsdb have been deprecated by JDK-8338894 since JDK 24. I agree with RMI removal from SA, but I'd like to keep remote debugger feature for some cases.

For example, sadebugd can be used to debug in distroless container on Kubernetes. As you know distroless container does not have any shell, and also no JDK tools including jhsdb. If we want to analyze hang-up'ed JVM in it with HSDB, we have to attach ephemeral container and expose the port for debugging to connect from HSDB.
I talked about use case of jhsdb debugd on Kubernetes (in Japanese...)
https://www.youtube.com/watch?v=5evMwwPUl14&t=346s

So I want to alternative it to HTTP:
   https://github.com/openjdk/jdk/compare/master...YaSuenag:jdk:http-sadebugd

This change works with some CLHSDB commands (jstack, findsym at least). Note that it has some errors and does not have some implementations and test cases.

You can use this following command:

   Server: jhsdb httpserver --host testhost --port 8080 --pid <PID>
   Client: jhsdb clhsdb --httpconnect http://testhost:8080/

This change transports debugging data on HTTP. We can set reverse proxy (for HTTPS endpoint and/or authentication) for secure connection if need.


Remote debugging removal has been filed as JDK-8340121. It does not seem to be targeted, but the work might be started soon. So I'd like to make alternatives by then.

What do you think?


Thanks,

Yasumasa

From coleenp at openjdk.org  Thu Jan  2 13:14:14 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:14:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v8]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <67hlSAvg5aEfWNhl2tj2Fe5FKNNXsJ8TsOCUe10KRQg=.54a14494-af1f-4bd0-a7dc-b5ece84ecd97@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Import @offamitkumar patch for s390.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/5a84b139..8cafd452

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

  Stats: 32 lines in 5 files changed: 15 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

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

From coleenp at openjdk.org  Thu Jan  2 13:14:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:14:15 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v7]
In-Reply-To: <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <LN8OLYpL7jLG920ljVWhyG4SWFIn9x2o_Iqrx91fx6Q=.997e0efb-2041-4b27-a2f6-36788ff2c18e@github.com>
Message-ID: <PfmZdTt-EA4Ly2yj5wmjB8seJ66hod1qVRIfvQJOr_k=.b3d9653e-3c2e-4cc9-9b3b-076cb066883b@github.com>

On Thu, 2 Jan 2025 13:08:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix lhz in ppc

Thank you for the patch Amit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2567753064

From coleenp at openjdk.org  Thu Jan  2 13:20:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 2 Jan 2025 13:20:20 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Happy New Year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/8cafd452..c60e96b4

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

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

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

From mdoerr at openjdk.org  Thu Jan  2 13:55:36 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 2 Jan 2025 13:55:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>
 <cVdgOEAgUWp259UB3t_g5vCp3pZ9do1JvV6aHZqBGRA=.817ec1c2-36b7-4d27-9249-2c4c7284effb@github.com>
Message-ID: <9uPHxBroRJc6lcPjNOMALruNbfomUw-zG3oxYJg_N10=.9b3e439b-d3ff-4092-a205-699e5f9921b9@github.com>

On Thu, 2 Jan 2025 13:05:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 149:
>> 
>>> 147:     // _access_flags must be a 16 bit value.
>>> 148:     assert(sizeof(AccessFlags) == 2, "wrong size");
>>> 149:     __ lha(R11_scratch1/*access_flags*/, method_(access_flags));
>> 
>> Using `lhz` would be more consistent. `lha` uses sign extend instead of zero extend. Feel free to clean this up if you want. Both instructions should work.
>
> I fixed this - it was the only one.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1900899700

From rriggs at openjdk.org  Thu Jan  2 18:34:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Jan 2025 18:34:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <dr1_0pthFJtf_cDfhekixQSS2XOPM92JjX3vT763Ne8=.3e52b7b1-3420-4e7c-9c35-3fe8b1335eab@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2528039527

From stooke at openjdk.org  Thu Jan  2 19:14:56 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 2 Jan 2025 19:14:56 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  refine jtreg tags per review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/1da4240d..9819f027

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

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

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

From sspitsyn at openjdk.org  Thu Jan  2 23:36:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 Jan 2025 23:36:41 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
Message-ID: <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>

On Thu, 2 Jan 2025 13:20:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Happy New Year

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1151:

> 1149:       // methods match, be sure modifiers do too
> 1150:       old_flags = k_old_method->access_flags().as_unsigned_short();
> 1151:       new_flags = k_new_method->access_flags().as_unsigned_short();

Nit: I'd suggest to use `as_method_flags()` and `as_class_flags()` at lines 1008-1009 to make it consistent with the lines 1043-1044. Good example is `jvmtiClassFileReconstituter.cpp`. Also, it would make sense to expend this rule to some other files, e.g.:
 `methodHandles.cpp`, `jvmtiEnv.cpp`, `jvm.cpp`, instanceClass.cpp`, `fieldInfo.inline.hpp`, `fieldInfo.cpp

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1901371957

From qxing at openjdk.org  Fri Jan  3 01:36:51 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <7dv3Q8SJD7soOx8rgXMB2_ZOf3RbwtcI7zuzybFjJoQ=.b875ea95-9e62-41b8-9898-0d7d21a14b5e@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Thank you all for your suggestions and reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568590393

From duke at openjdk.org  Fri Jan  3 01:36:51 2025
From: duke at openjdk.org (duke)
Date: Fri, 3 Jan 2025 01:36:51 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <6jso7rCfR9hvxiCw9z222ueaJQxQol9ELecOcr5BQxQ=.d399c10e-79bd-4f4f-9ed1-91f777c3cb8a@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

@MaxXSoft 
Your change (at version 7f85c5e30ab69fe2f94d4604073eb8e610bfc6c2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2568591104

From amenkov at openjdk.org  Fri Jan  3 02:03:08 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 3 Jan 2025 02:03:08 GMT
Subject: RFR: 8342996: Enhance Attach API to support arbitrary length arguments
 - OSX
Message-ID: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>

The fix updates client side of OSX implementation to support Attach API v2.
Server side is shared with Linux and was updated by #22223.
The changes are identical to client-side changes for Linux from #22223.

Testing: tier1,tier2,tier3,tier4,hs-tier5-svc

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

Commit messages:
 - attach_v2_osx

Changes: https://git.openjdk.org/jdk/pull/22907/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22907&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342996
  Stats: 52 lines in 1 file changed: 15 ins; 26 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/22907.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22907/head:pull/22907

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

From amitkumar at openjdk.org  Fri Jan  3 07:49:43 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 3 Jan 2025 07:49:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
Message-ID: <wnb5Aet32sQo0Qb7r7NI7FYyGwRuaNVVZL8vRe-JkeE=.3e546c1f-f800-47b6-9346-5d260a87d44e@github.com>

On Thu, 2 Jan 2025 13:20:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Happy New Year

Thanks for adding the patch Coleen :-) 

 I did another test-run and s390x looks fine now.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2568808253

From asotona at openjdk.org  Fri Jan  3 13:07:18 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 3 Jan 2025 13:07:18 GMT
Subject: RFR: 8346985: Convert test/jdk/com/sun/jdi/ClassUnloadEventTest.java
 to Class-File API
Message-ID: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>

This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8346985: Convert test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API

Changes: https://git.openjdk.org/jdk/pull/22915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346985
  Stats: 20 lines in 1 file changed: 3 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22915/head:pull/22915

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

From coleenp at openjdk.org  Fri Jan  3 14:38:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 14:38:22 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
Message-ID: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>

There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.

Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

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

Commit messages:
 - 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

Changes: https://git.openjdk.org/jdk/pull/22916/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346990
  Stats: 339 lines in 83 files changed: 0 ins; 13 del; 326 mod
  Patch: https://git.openjdk.org/jdk/pull/22916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22916/head:pull/22916

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

From jwaters at openjdk.org  Fri Jan  3 15:43:41 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Jan 2025 15:43:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <GB7FT__OPX76lA3Ch8Uwjb5So6JcI-K4ZFQ2ox3uC38=.d2072422-4281-418d-beff-cbb16c1afdcb@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Speaking of %z, there is a non Standard %Ix in os_windows.cpp


tty->print_cr("reserve_memory of %Ix bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,
                    reserveTimer.milliseconds(), reserveTimer.ticks());


Could changing that to %zu be trivial enough to fit into this change?

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569435948

From coleenp at openjdk.org  Fri Jan  3 16:23:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:31 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix %Ix to %zx.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6d6fbfa7..1748797a

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

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

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

From coleenp at openjdk.org  Fri Jan  3 16:23:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 16:23:32 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <PqP9LcFOEMsX5bVeywyEEEdBVvHSp7y6axjHAOgCYIw=.24eb6982-7cb1-4686-a2ba-a6fc0500f80a@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

I was going to take on the other FORMAT ones in separate PRs.
Sorry I see what you're saying.  yes, I'll fix that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2569484010

From liach at openjdk.org  Fri Jan  3 16:49:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 3 Jan 2025 16:49:40 GMT
Subject: RFR: 8346985: Convert
 test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API
In-Reply-To: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
References: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
Message-ID: <UvezOjt0SsNMI73Ch73tIXlDM59W8mhuxIaTcVi-6Dc=.d17b3773-ff7c-4f23-8d4a-34aad4dcee9a@github.com>

On Fri, 3 Jan 2025 13:02:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by liach (Reviewer).

test/jdk/com/sun/jdi/ClassUnloadEventTest.java line 72:

> 70:             ClassWriter cw = new ClassWriter(0);
> 71: 
> 72:             cw.visit(52, ACC_SUPER | ACC_PUBLIC, name, null, "java/lang/Object", null);

This anticipates an internal name but gets a binary name passed. This works in the old code accidentally because its classes were in the unnamed package.  The port fixes this bug.

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

PR Review: https://git.openjdk.org/jdk/pull/22915#pullrequestreview-2529398187
PR Review Comment: https://git.openjdk.org/jdk/pull/22915#discussion_r1901972466

From sspitsyn at openjdk.org  Fri Jan  3 17:57:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 Jan 2025 17:57:34 GMT
Subject: RFR: 8342996: Enhance Attach API to support arbitrary length
 arguments - OSX
In-Reply-To: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
References: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
Message-ID: <W2-z94lziWutOZ3h45v4fBPykqy2fyBSL7cIS6sqrIk=.1a6c6caf-a69e-4ad7-9944-7e12df90f6bb@github.com>

On Fri, 3 Jan 2025 01:57:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates client side of OSX implementation to support Attach API v2.
> Server side is shared with Linux and was updated by #22223.
> The changes are identical to client-side changes for Linux from #22223.
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22907#pullrequestreview-2529490664

From coleenp at openjdk.org  Fri Jan  3 19:22:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 19:22:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v9]
In-Reply-To: <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <gA9yitti1PVes8_ocmob1uVjBj8i-6mtBLLpHI2Qyfo=.d89946de-91c5-4215-9ca1-757357577374@github.com>
 <Ukn4bU2zbBzr7L7sQkE_E5LCyLIjBa2vWQrsO0Fj114=.8531d459-2666-41d1-b702-b798c5d3f670@github.com>
Message-ID: <5-GUDe1mvBa86obIcZdPrzFkXtrXU7Epn9ol6pxfHbE=.a90acfed-bece-4d9d-a56b-6981a52cbbb0@github.com>

On Thu, 2 Jan 2025 23:33:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Happy New Year
>
> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1151:
> 
>> 1149:       // methods match, be sure modifiers do too
>> 1150:       old_flags = k_old_method->access_flags().as_unsigned_short();
>> 1151:       new_flags = k_new_method->access_flags().as_unsigned_short();
> 
> Nit: I'd suggest to use `as_method_flags()` and `as_class_flags()` at lines 1008-1009 to make it consistent with the lines 1043-1044. Good example is `jvmtiClassFileReconstituter.cpp`. Also, it would make sense to expend this rule to some other files, e.g.: `method.cpp`, `methodHandles.cpp`, `jvmtiEnv.cpp`, `jvm.cpp`, `instanceClass.cpp`, `fieldInfo.inline.hpp`, `fieldInfo.cpp`

This is a good suggestion.  I strengthened the as_{field|method|class}_flags functions because they should be stored with only their recognized modifiers in the appropriate place.  Retesting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1902091752

From stooke at openjdk.org  Fri Jan  3 20:10:35 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Fri, 3 Jan 2025 20:10:35 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@github.com>
Message-ID: <TvCaB-h4ouwH0lAcEhVWa5NYdGQjkD5zAOjZlUiWlA4=.b9956a7f-0dd7-4742-af07-e4aa1e0f6a90@github.com>

On Wed, 25 Dec 2024 00:26:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine jtreg tags per review
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:
> 
>> 37:  *          java.management
>> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
>> 39:  * @run testng/othervm -XX:+UsePerfData -XX:+UseZGC SystemMapTest
> 
> No need to add separate testcase for ZGC. It is expected that  hotspot tests are usually executed to ensure that all functionality works with any GC.
> If you want to add it to ensure that  regression testcase is always executed even no ZGC is set then please 
> 1) add
> `* @requires vm.gc.Z`
> So testcase is not executed if non-ZGC GC (Parallel/Serial etc) is set explicitly.
> 2) Add 
> ` * @bug 8346717`
> 3) Add id like
> `* @test id=zgc`
> to make testcase name clearer.

@lmesnik thank you for the review!  I have updated the jtreg tags as suggested.  My intent is to ensure this test is run with and without ZGC as the expected results differ.  I believe I can accomplish this with these two test definitions?  I've seen similar test definitions elsewhere in the jdk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1902126817

From coleenp at openjdk.org  Fri Jan  3 21:54:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 21:54:26 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v10]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <X28oWuUDJ1j-p0Gds7qSo7MMgBLry1CZPORSWexezYQ=.a4a3021d-639e-40a4-a1cb-8bceff542bb3@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Adopt @sspitsyn suggestion and strengthen field/method/class flag retrieval.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/c60e96b4..8682a778

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=08-09

  Stats: 36 lines in 9 files changed: 11 ins; 5 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

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

From coleenp at openjdk.org  Fri Jan  3 22:00:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 3 Jan 2025 22:00:34 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix more copyrights.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/8682a778..82bd1a24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=09-10

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

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

From kbarrett at openjdk.org  Sat Jan  4 10:04:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 4 Jan 2025 10:04:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Uses of `[U]INTX_FORMAT_X` have been replaced with `0x%zx`.  I mentioned the
possibility of instead using `%#zx`.  I don't know if we really want to use some of
the (to me) more obscure flag options though.

src/hotspot/cpu/x86/vm_version_x86.cpp line 1725:

> 1723:         ArrayOperationPartialInlineSize = MaxVectorSize >= 16 ? MaxVectorSize : 0;
> 1724:         if (ArrayOperationPartialInlineSize) {
> 1725:           warning("Setting ArrayOperationPartialInlineSize as MaxVectorSize%zd)", MaxVectorSize);

pre-existing: seems like there should be a separator of some kind between "MaxVectorSize" and the
value, either a space or an "=" would be okay.

src/hotspot/os/linux/os_linux.cpp line 1370:

> 1368: 
> 1369: #define _UFM "%zu"
> 1370: #define _DFM "%zd"

Why not get rid of these?

src/hotspot/share/ci/ciMethodData.cpp line 788:

> 786:     // which makes comparing it with the SA version of this output
> 787:     // harder. data()'s element type is intptr_t.
> 788:     out->print(" 0x%zx", data()[i]);

Could instead use " %#zx".

src/hotspot/share/compiler/disassembler.cpp line 600:

> 598:         st->print("Stub::%s", desc->name());
> 599:         if (desc->begin() != adr) {
> 600:           st->print("%+zd " PTR_FORMAT, adr - desc->begin(), p2i(adr));

Oh, that's an interesting "abuse" of the `_W` variant.

src/hotspot/share/gc/shared/ageTable.cpp line 38:

> 36: #include "logging/logStream.hpp"
> 37: 
> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.

Well this is weird.  An atypical copyright down inside the file?

src/hotspot/share/oops/instanceKlass.cpp line 3695:

> 3693: 
> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();

Should be using "zx" rather than "zu".   I think this could be written as 
`"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
That's looking a lot like line noise though.  I think this and ones like it probably ought not be
changed at all.

src/hotspot/share/oops/klass.cpp line 1308:

> 1306:   if (secondary_supers() != nullptr) {
> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);

Same as in instanceKlass - maybe this shouldn't be changed at all.

src/hotspot/share/utilities/globalDefinitions.hpp line 156:

> 154: #define UINTX_FORMAT_X_0         "0x%016"     PRIxPTR
> 155: #else
> 156: #define UINTX_FORMAT_X_0         "0x%08"      PRIxPTR

As noted in places where it's used, I'm not sure we should remove and replace UINTX_FORMAT_X_0.

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:

> 279: 
> 280:   check_format("%zd",                  (intx)123,         "123");
> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");

Could be "%#zx".

test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 286:

> 284: 
> 285:   check_format("%zu",                  (uintx)123u,       "123");
> 286:   check_format("0x%zx",                (uintx)0x123u,     "0x123");

Could be "%#zx".

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2530503795
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902879593
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902886743
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902972028
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902912020
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902916165
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902944144
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902945394
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902960940
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902965078
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1902966477

From duke at openjdk.org  Sat Jan  4 17:21:43 2025
From: duke at openjdk.org (duke)
Date: Sat, 4 Jan 2025 17:21:43 GMT
Subject: Withdrawn: 8336691: Test LongArgTest.java intermittent fails
 java.lang.NoClassDefFoundError: jdk/test/lib/Utils
In-Reply-To: <xhUV2ffVMkc6E1deYIHwypIzvbSPkgs4eVOW2h9c3Uw=.27519676-0d2d-48df-95d8-2c34d1c981b6@github.com>
References: <xhUV2ffVMkc6E1deYIHwypIzvbSPkgs4eVOW2h9c3Uw=.27519676-0d2d-48df-95d8-2c34d1c981b6@github.com>
Message-ID: <u3F7u6oucJvjI3ukbMJuca0RsiOM8VCe-C6z0q0kslU=.6fbff123-9386-41c1-96e7-be7496798601@github.com>

On Thu, 18 Jul 2024 01:49:54 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg  framework bug.
> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly.
> Only change the testcase, the change has been verified, no risk.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Mon Jan  6 04:00:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 04:00:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
Message-ID: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>

On Fri, 3 Jan 2025 22:00:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix more copyrights.

src/hotspot/share/ci/ciFlags.cpp line 95:

> 93: // ciFlags::print
> 94: void ciFlags::print(outputStream* st) {
> 95:   st->print(" flags=%x", _flags.as_unsigned_short());

Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?

src/hotspot/share/ci/ciFlags.hpp line 71:

> 69: 
> 70:   // Conversion
> 71:   jint   as_int()                      { return _flags.as_unsigned_short(); }

It is unclear to me whether the fact we are dealing with u2 should be exposed in this API as well.

src/hotspot/share/ci/ciKlass.cpp line 225:

> 223:   assert(is_loaded(), "not loaded");
> 224:   GUARDED_VM_ENTRY(
> 225:     return get_Klass()->access_flags().as_unsigned_short();

Again it is unclear to me whether this API should also now return u2.

src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1003:

> 1001:     JVMCI_ERROR_NULL("info must not be null and have a length of 4");
> 1002:   }
> 1003:   JVMCIENV->put_int_at(info, 0, fd.access_flags().as_unsigned_short());

Again are we relying on implicit widening from u2 to int?

It really isn't clear to me whether the only thing we should have changed here is the actual type of the `_flags` field and let everything else continue to represent flags as int, so we don't get these transitions from u2 to int  in these higher level APIs.

src/hotspot/share/jvmci/jvmciEnv.cpp line 1595:

> 1593:     HotSpotJVMCI::FieldInfo::set_signatureIndex(JVMCIENV, obj_h(), (jint)fieldinfo->signature_index());
> 1594:     HotSpotJVMCI::FieldInfo::set_offset(JVMCIENV, obj_h(), (jint)fieldinfo->offset());
> 1595:     HotSpotJVMCI::FieldInfo::set_classfileFlags(JVMCIENV, obj_h(), (jint)fieldinfo->access_flags().as_unsigned_short());

I'm curious why we need the explicit cast here - is it because we are going from unsigned to signed?

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java line 82:

> 80:   public int getStandardFlags() {
> 81:     return (int)flags;
> 82:   }

This function seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903619988
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903621196
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903621733
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903624061
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903624365
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1903619429

From dholmes at openjdk.org  Mon Jan  6 05:02:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 05:02:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
Message-ID: <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>

On Mon, 23 Dec 2024 15:26:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comments, remove unneeded ifdef, remove typo

In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2531327078

From dholmes at openjdk.org  Mon Jan  6 06:21:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 06:21:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v2]
In-Reply-To: <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <fiZAIh_ms_gL7r5_KClBPISG-OE2CQI0MRivcZDVi3Y=.b5b443a2-3e83-4b9b-b1ad-c33f4c538e74@github.com>
Message-ID: <vI9uVfk-fbBeeh-qRip2v6hGVyNjnINVWBoPGuu-gMg=.274f3c10-a650-416a-857b-ec3681aad19e@github.com>

On Thu, 2 Jan 2025 19:14:56 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refine jtreg tags per review

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 45:

> 43: 
> 44: /*
> 45:  * @test id=normal

The normal test should be for non-ZGC otherwise in a test config that runs everything with ZGC you will run them both when only one is needed

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

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2531420841
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1903716217

From dholmes at openjdk.org  Mon Jan  6 06:26:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <Sku5_RiFCfq5hUWlIPyPuShlTEkUjy1puhFyRXD-3PM=.22b1336d-2876-41dd-bb9e-8384c84983ba@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

LGTM2.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2531429430

From qxing at openjdk.org  Mon Jan  6 06:26:47 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 6 Jan 2025 06:26:47 GMT
Subject: Integrated: 8346773: Fix unmatched brackets in some misc files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <MGlZQfhGaTFiQzpqY86SF5FGLMjKbQ9ibj_l678R8Os=.25c31ede-ade3-4e04-ace9-f69db071d95a@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some files, mostly in comments, docs and man pages.

This pull request has now been integrated.

Changeset: f1d85ab3
Author:    Qizheng Xing <qxing at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f1d85ab3e61f923b4e120cf30e16109e04505b53
Stats:     10 lines in 7 files changed: 0 ins; 0 del; 10 mod

8346773: Fix unmatched brackets in some misc files

Reviewed-by: kbarrett, alanb, rriggs, dholmes, erikj, liach

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

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

From asotona at openjdk.org  Mon Jan  6 08:58:11 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 08:58:11 GMT
Subject: RFR: 8346985: Convert
 test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API [v2]
In-Reply-To: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
References: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
Message-ID: <pU4HF3vps0Im5k-90V8i7hOXU7chkWpS0oxXYTP-SyM=.677bfb91-188b-47ad-8242-d84d0cee1e4d@github.com>

> This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22915/files
  - new: https://git.openjdk.org/jdk/pull/22915/files/bc0b9dfa..9e8471d8

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

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

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

From coleenp at openjdk.org  Mon Jan  6 13:46:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 13:46:40 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
Message-ID: <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>

On Mon, 6 Jan 2025 03:44:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix more copyrights.
>
> src/hotspot/share/ci/ciFlags.cpp line 95:
> 
>> 93: // ciFlags::print
>> 94: void ciFlags::print(outputStream* st) {
>> 95:   st->print(" flags=%x", _flags.as_unsigned_short());
> 
> Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?

Yes, we are.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904168828

From liach at openjdk.org  Mon Jan  6 14:08:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 14:08:47 GMT
Subject: RFR: 8346985: Convert
 test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API [v2]
In-Reply-To: <pU4HF3vps0Im5k-90V8i7hOXU7chkWpS0oxXYTP-SyM=.677bfb91-188b-47ad-8242-d84d0cee1e4d@github.com>
References: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
 <pU4HF3vps0Im5k-90V8i7hOXU7chkWpS0oxXYTP-SyM=.677bfb91-188b-47ad-8242-d84d0cee1e4d@github.com>
Message-ID: <N7ZQ5jx04aD2jjmTpljYWqtj42jovBAEaipX7cXA--M=.57e87c5f-51da-48c3-bc08-5782af64cb02@github.com>

On Mon, 6 Jan 2025 08:58:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22915#pullrequestreview-2532212678

From coleenp at openjdk.org  Mon Jan  6 14:12:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:56 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused SA function.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/82bd1a24..d43b2fac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=10-11

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

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

From coleenp at openjdk.org  Mon Jan  6 14:12:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:56 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
 <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
Message-ID: <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>

On Mon, 6 Jan 2025 13:44:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/ci/ciFlags.cpp line 95:
>> 
>>> 93: // ciFlags::print
>>> 94: void ciFlags::print(outputStream* st) {
>>> 95:   st->print(" flags=%x", _flags.as_unsigned_short());
>> 
>> Here, and elsewhere, are we relying on an implicit widening of the u2 result to int so that the format specifier is correct?
>
> Yes, we are.

I had a little experiment.

extern "C" int printf(const char *,...);
int main() {
  unsigned short ss = 0x8000;
  printf("does unsigned sign extend to int? %d\n", int(ss));
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904172191

From coleenp at openjdk.org  Mon Jan  6 14:12:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 14:12:57 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
Message-ID: <Smg6Y1T71YK2CbadjB67kWZS05cXCecGZFCI2KZmbOY=.04893819-ba04-482f-826b-04ddd7381cce@github.com>

On Mon, 6 Jan 2025 03:47:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix more copyrights.
>
> src/hotspot/share/ci/ciFlags.hpp line 71:
> 
>> 69: 
>> 70:   // Conversion
>> 71:   jint   as_int()                      { return _flags.as_unsigned_short(); }
> 
> It is unclear to me whether the fact we are dealing with u2 should be exposed in this API as well.

I don't think it should be.

> src/hotspot/share/ci/ciKlass.cpp line 225:
> 
>> 223:   assert(is_loaded(), "not loaded");
>> 224:   GUARDED_VM_ENTRY(
>> 225:     return get_Klass()->access_flags().as_unsigned_short();
> 
> Again it is unclear to me whether this API should also now return u2.

I don't think it should.  I think the boundary of where we promote the u2 to int should be at this API.  If those working on the compiler code would like to propagate the size of the storage (u2) around, they can decide to do that.

> src/hotspot/share/jvmci/jvmciCompilerToVM.cpp line 1003:
> 
>> 1001:     JVMCI_ERROR_NULL("info must not be null and have a length of 4");
>> 1002:   }
>> 1003:   JVMCIENV->put_int_at(info, 0, fd.access_flags().as_unsigned_short());
> 
> Again are we relying on implicit widening from u2 to int?
> 
> It really isn't clear to me whether the only thing we should have changed here is the actual type of the `_flags` field and let everything else continue to represent flags as int, so we don't get these transitions from u2 to int  in these higher level APIs.

Yes, we can widen u2 to int.  See above.  The ci code represents the integral value of access flags as jint.  I am leaving that API in place.  For this, the widening happens when fetching the u2 field.  The conversion is implicit.  If this field were to be stored back to a u2 somewhere, all the code in the compiler should change but the current code doesn't do that.

> src/hotspot/share/jvmci/jvmciEnv.cpp line 1595:
> 
>> 1593:     HotSpotJVMCI::FieldInfo::set_signatureIndex(JVMCIENV, obj_h(), (jint)fieldinfo->signature_index());
>> 1594:     HotSpotJVMCI::FieldInfo::set_offset(JVMCIENV, obj_h(), (jint)fieldinfo->offset());
>> 1595:     HotSpotJVMCI::FieldInfo::set_classfileFlags(JVMCIENV, obj_h(), (jint)fieldinfo->access_flags().as_unsigned_short());
> 
> I'm curious why we need the explicit cast here - is it because we are going from unsigned to signed?

The casts were all there for all these fields, so I left it.  It is unnecessary but matches the style of the preceding lines.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/AccessFlags.java line 82:
> 
>> 80:   public int getStandardFlags() {
>> 81:     return (int)flags;
>> 82:   }
> 
> This function seems unused.

Ah thanks.  Another SA function to remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904197071
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904190829
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904193482
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904194643
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904195078

From asotona at openjdk.org  Mon Jan  6 14:13:49 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 14:13:49 GMT
Subject: Integrated: 8346985: Convert
 test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API
In-Reply-To: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
References: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
Message-ID: <YMoxxY3UYcg6r-7i9-JSZY2tCnmi6H0DVvVB5L7kFtM=.da70c8bf-c8f0-419c-a0a2-d1c03bdade8b@github.com>

On Fri, 3 Jan 2025 13:02:07 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ccf3d57e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ccf3d57ebcae718336770a4c3fc896d85340df23
Stats:     21 lines in 1 file changed: 3 ins; 10 del; 8 mod

8346985: Convert test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API

Reviewed-by: liach

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

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

From asotona at openjdk.org  Mon Jan  6 14:13:49 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 14:13:49 GMT
Subject: RFR: 8346985: Convert
 test/jdk/com/sun/jdi/ClassUnloadEventTest.java to Class-File API [v2]
In-Reply-To: <pU4HF3vps0Im5k-90V8i7hOXU7chkWpS0oxXYTP-SyM=.677bfb91-188b-47ad-8242-d84d0cee1e4d@github.com>
References: <RzfbOrHfto19Ah_ZD1fGaKnvLMT4E_oGFrILiQiTIi0=.8f6144b4-a702-4ad8-876b-a3d9044eb949@github.com>
 <pU4HF3vps0Im5k-90V8i7hOXU7chkWpS0oxXYTP-SyM=.677bfb91-188b-47ad-8242-d84d0cee1e4d@github.com>
Message-ID: <i7FvkwcPTB1nhpPk91EqbtFdkufYnq132Zdrb8ONC-A=.e57c5d08-d3be-4237-8ff5-6b2635352751@github.com>

On Mon, 6 Jan 2025 08:58:11 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This patch converts the remaining test/jdk/com/sun/jdi/ClassUnloadEventTest.java from ASM to Class-File API.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Thank you for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22915#issuecomment-2573187773

From coleenp at openjdk.org  Mon Jan  6 15:09:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v3]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <v-l_S89jSVDIGrgoEHbJG3MGPELL_w4CYjPS2vE7lFc=.6a1fb33c-f2ba-48c6-a3d1-fe4463a492dd@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fixed some code review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/1748797a..15b1052a

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

  Stats: 16 lines in 5 files changed: 0 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22916/head:pull/22916

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

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
Message-ID: <3vQ-kxRahCEhGLRshu6KE_0ZkWCnrgtnyx8cbXsPIeE=.24a34a54-28b0-4202-8ea3-6bd2b7325ce3@github.com>

On Fri, 3 Jan 2025 16:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix %Ix to %zx.

Kim, thanks for slogging through this change.  I've updated the patch with your suggested changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2573301941

From coleenp at openjdk.org  Mon Jan  6 15:09:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:09:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>

On Sat, 4 Jan 2025 09:02:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/os/linux/os_linux.cpp line 1370:
> 
>> 1368: 
>> 1369: #define _UFM "%zu"
>> 1370: #define _DFM "%zd"
> 
> Why not get rid of these?

Fixed.

> src/hotspot/share/gc/shared/ageTable.cpp line 38:
> 
>> 36: #include "logging/logStream.hpp"
>> 37: 
>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
> 
> Well this is weird.  An atypical copyright down inside the file?

This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

> src/hotspot/share/oops/instanceKlass.cpp line 3695:
> 
>> 3693: 
>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
> 
> Should be using "zx" rather than "zu".   I think this could be written as 
> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
> changed at all.

I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264225
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904264062
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904263162

From coleenp at openjdk.org  Mon Jan  6 15:24:18 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:18 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v4]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <TL-PdaGpWb-cAJFmKJrMKkNy1L5wkbFZFxU1Kt0_KkY=.d541d19d-0014-4be1-88c5-fab6e1f76c3b@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use INTPTR_FORMAT instead of zu for secondary_supers_bitmap.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/15b1052a..6e8b2702

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=02-03

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

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

From coleenp at openjdk.org  Mon Jan  6 15:24:19 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 15:24:19 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>

On Mon, 6 Jan 2025 15:03:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 3695:
>> 
>>> 3693: 
>>> 3694:   st->print(BULLET"hash_slot:         %d", hash_slot()); st->cr();
>>> 3695:   st->print(BULLET"secondary bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap); st->cr();
>> 
>> Should be using "zx" rather than "zu".   I think this could be written as 
>> `"%#0*zx", (2 * BytesPerWord + 2), _secondary_supers_bitmap`
>> That's looking a lot like line noise though.  I think this and ones like it probably ought not be
>> changed at all.
>
> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.

@theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904284828

From coleenp at openjdk.org  Mon Jan  6 16:02:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 6 Jan 2025 16:02:36 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <XNMHk0Rh8KL4VxuqCHjK7agSagK9tG2hgXWm1_l8lEg=.72ef1aa2-5d33-4add-93af-291c969c418f@github.com>

On Sat, 4 Jan 2025 09:52:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
> 
>> 279: 
>> 280:   check_format("%zd",                  (intx)123,         "123");
>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
> 
> Could be "%#zx".

I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1904331779

From sspitsyn at openjdk.org  Mon Jan  6 17:10:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 6 Jan 2025 17:10:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
Message-ID: <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>

On Mon, 6 Jan 2025 14:12:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused SA function.

Thank you for update with this an unification!
I've posted a couple of comments with similar nits.

src/hotspot/share/interpreter/linkResolver.cpp line 586:

> 584:     // We need to change "protected" to "public".
> 585:     assert(flags.is_protected(), "clone not protected?");
> 586:     u2 new_flags = flags.as_unsigned_short();

Nit: Should this also be replaced with `as_method_flags()`?

src/hotspot/share/opto/memnode.cpp line 1985:

> 1983:     // The field is Klass::_access_flags.  Return its (constant) value.
> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
> 1985:     assert(this->Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");

Nit: This can be unified with line 1979 and also get rid of `this->`.

src/hotspot/share/prims/jvm.cpp line 2472:

> 2470:   u2 field_access_flags = InstanceKlass::cast(k)->field_access_flags(field_index);
> 2471:   // This & should be unnecessary.
> 2472:   assert((field_access_flags & JVM_RECOGNIZED_FIELD_MODIFIERS) == field_access_flags, "already masked");

Nit: Yes, it is better to remove the lines: 2471-2472.

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

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2532540668
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904386978
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904405970
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904404626

From kevin.walls at oracle.com  Mon Jan  6 17:21:35 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 6 Jan 2025 17:21:35 +0000
Subject: [External] : Alternative to sadebugd
In-Reply-To: <44818014-55cf-4e3f-aef0-96950c8b1cd5@gmail.com>
References: <44818014-55cf-4e3f-aef0-96950c8b1cd5@gmail.com>
Message-ID: <SN7PR10MB70328CEFF18AF35148CB3AB297102@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi -

I created JDK-8340121 to have the actual removal of RMI features visible... on the horizon somewhere... I did not mean to suggest it is going away very very soon.  I don't want to make a forward-looking statement or a promise, but I do not expect this to be acted on right now.  But I also don't want us to forget the idea of removing it in future.

Will need to look at your idea in more detail.

If there is any resistance or reason not to do this in the JDK, then I guess it's something that does not absolutely have to be in the JDK itself.  A proxy-like tool that is outside the JDK can work.  Yes it is likely more convenient to use if it's bundled in the JDK, but we would need to balance that convenience for some users with any ongoing maintenance etc for others.

Thanks
Kevin


-----Original Message-----
From: Yasumasa Suenaga <yasuenag at gmail.com> 
Sent: Thursday, January 2, 2025 1:12 PM
To: serviceability-dev at openjdk.org
Cc: Yasumasa Suenaga <suenaga at oss.nttdata.com>; Kevin Walls <kevin.walls at oracle.com>
Subject: [External] : Alternative to sadebugd

Hi all,

sadebugd and related options in jhsdb have been deprecated by JDK-8338894 since JDK 24. I agree with RMI removal from SA, but I'd like to keep remote debugger feature for some cases.

For example, sadebugd can be used to debug in distroless container on Kubernetes. As you know distroless container does not have any shell, and also no JDK tools including jhsdb. If we want to analyze hang-up'ed JVM in it with HSDB, we have to attach ephemeral container and expose the port for debugging to connect from HSDB.
I talked about use case of jhsdb debugd on Kubernetes (in Japanese...) https://urldefense.com/v3/__https://www.youtube.com/watch?v=5evMwwPUl14&t=346s__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQRGV_0QBQ$ 

So I want to alternative it to HTTP:
   https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...YaSuenag:jdk:http-sadebugd__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQQf3ZTEeQ$ 

This change works with some CLHSDB commands (jstack, findsym at least). Note that it has some errors and does not have some implementations and test cases.

You can use this following command:

   Server: jhsdb httpserver --host testhost --port 8080 --pid <PID>
   Client: jhsdb clhsdb --httpconnect https://urldefense.com/v3/__http://testhost:8080/__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQQeBBszCA$ 

This change transports debugging data on HTTP. We can set reverse proxy (for HTTPS endpoint and/or authentication) for secure connection if need.


Remote debugging removal has been filed as JDK-8340121. It does not seem to be targeted, but the work might be started soon. So I'd like to make alternatives by then.

What do you think?


Thanks,

Yasumasa

From pchilanomate at openjdk.org  Mon Jan  6 17:42:09 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 6 Jan 2025 17:42:09 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() || stub_caller)
 failed: expected a stub-caller
Message-ID: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>

Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.

Thanks,
Patricio

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

Commit messages:
 - v1

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

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

From duke at openjdk.org  Mon Jan  6 19:21:38 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 6 Jan 2025 19:21:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
Message-ID: <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>

On Mon, 6 Jan 2025 05:00:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.

I think that the `WatcherThread` does use NMT (at least upon starting), since `Thread::call_run() ` calls `register_thread_stack_with_NMT()`. However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still  be used. So checking `WatcherThread::watcher_thread() != nullptr` may not work in this case as it could be set back to nullptr too early.

Another solution might be to introduce something like `Threads::is_single_threaded()` which checks for  `WatcherThread`, `Threads::number_of_threads()`, and any other threads that fall outside this set. I'm not sure whether that would be better than the current approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2573756615

From dholmes at openjdk.org  Mon Jan  6 21:22:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Jan 2025 21:22:36 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Looks good to me. Thanks for the detailed analysis.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2532992481

From amenkov at openjdk.org  Tue Jan  7 01:08:34 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 7 Jan 2025 01:08:34 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <0mDCq1sgRxClxhFMlEaMQ7gGS3FYpdE0YG8gFx8o-pY=.09ca389d-c5bc-4412-bb86-23072b03b72c@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2533212184

From dholmes at openjdk.org  Tue Jan  7 02:20:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 02:20:40 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
Message-ID: <ecI3DkqeGCxK7E_fIxTgB7xliqBShOXxu_5zHUMCB6g=.699b4ece-9bd1-46e4-af78-483b901792d4@github.com>

On Mon, 6 Jan 2025 14:12:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused SA function.

I can't say that I really understand which API's are fine with flags-as-int and which need to care about the actual flag storage size. but I'll leave it at that. I will tick approve for the shared code portion of the change.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2533262347

From coleenp at openjdk.org  Tue Jan  7 02:30:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:30:49 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v12]
In-Reply-To: <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_Nd9lufPBNKwwKpbwtzX_inqoRVIqx8o11ZIWvXo98=.252254e2-92a4-4f0b-ae82-4aa01dc0a84b@github.com>
 <dpp8tNlLHaGLazlY_aNMZoTltHm0ESrZHqTs8ONilRE=.fffcccd5-65a8-4a6a-8289-b1784c7e4862@github.com>
Message-ID: <ptC2BTpeVx3DHvfoMtnSF27uw7ar8xNz9fN3wty8z3o=.6e33f566-2ee8-4381-a430-e473c3eea65a@github.com>

On Mon, 6 Jan 2025 16:46:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused SA function.
>
> src/hotspot/share/interpreter/linkResolver.cpp line 586:
> 
>> 584:     // We need to change "protected" to "public".
>> 585:     assert(flags.is_protected(), "clone not protected?");
>> 586:     u2 new_flags = flags.as_unsigned_short();
> 
> Nit: Should this also be replaced with `as_method_flags()`?

Thanks Serguei, I replaced this one and a couple of as_field_flags() so that as_unsigned_short() is more limited to the cases where we don't want masking.

> src/hotspot/share/opto/memnode.cpp line 1985:
> 
>> 1983:     // The field is Klass::_access_flags.  Return its (constant) value.
>> 1984:     // (Folds up the 2nd indirection in Reflection.getClassAccessFlags(aClassConstant).)
>> 1985:     assert(this->Opcode() == Op_LoadUS, "must load an unsigned short from _access_flags");
> 
> Nit: This can be unified with line 1979 and also get rid of `this->`.

1979 and 1985 are in different branches of an if statement (address of modifier flags vs access flags) so needs to be repeated.  But I did remove the this->

> src/hotspot/share/prims/jvm.cpp line 2472:
> 
>> 2470:   u2 field_access_flags = InstanceKlass::cast(k)->field_access_flags(field_index);
>> 2471:   // This & should be unnecessary.
>> 2472:   assert((field_access_flags & JVM_RECOGNIZED_FIELD_MODIFIERS) == field_access_flags, "already masked");
> 
> Nit: Yes, it is better to remove the lines: 2471-2472.

fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904829376
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904830369
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904829864

From coleenp at openjdk.org  Tue Jan  7 02:36:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:36:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Make more AccessFlags fetches more specific and remove an assert and remove this->s.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/d43b2fac..35784c70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=11-12

  Stats: 16 lines in 10 files changed: 0 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

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

From coleenp at openjdk.org  Tue Jan  7 02:47:37 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 02:47:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <NsIbHdXDhv6qsSp8Lt0S1hIMNipKFRDNCQ_8NI6SBBc=.bcfbec8c-9f81-4cc2-a1d9-327b7d274da2@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Thanks David.  I'm hoping @iwanowww or @dean-long  can review the compiler parts.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2574287163

From lmesnik at openjdk.org  Tue Jan  7 03:14:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 7 Jan 2025 03:14:46 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003 fails
 with java.lang.OutOfMemoryError when CDS is off
Message-ID: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>

Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.

Verified that it pass now with CDS off with and without UseCompactObjectHeaders.

I removed also other heap limits just because they are not needed and only might confuse test readers.

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

Commit messages:
 - 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003 fails with java.lang.OutOfMemoryError when CDS is off

Changes: https://git.openjdk.org/jdk/pull/22936/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22936&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346998
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22936.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22936/head:pull/22936

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

From dlong at openjdk.org  Tue Jan  7 03:20:38 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 03:20:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <7RpN7gvi4yXmEGG03o8JTg68OzymPhL76j6ndM4JPe8=.f5bcf133-ae7f-4efb-8df4-f8f9d6423b2d@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Sure, I'll try to take a look at it tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2574313889

From dholmes at openjdk.org  Tue Jan  7 04:22:35 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 04:22:35 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
Message-ID: <iimUmbOmazgEuv-W28OEWjUP04nUPhNnFlcPijwXgEk=.16451a10-d1ad-4a1a-8093-dc717edffd4b@github.com>

On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.
> 
> Verified that it pass now with CDS off with and without UseCompactObjectHeaders.
> 
> I removed also other heap limits just because they are not needed and only might confuse test readers.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java line 43:

> 41:  *      -agentlib:resexhausted=-waittime=5
> 42:  *      -Xms64m
> 43:  *      -Xmx64m

Don't you need these to ensure we get OOME in a reasonable amount of time on systems with huge memories?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22936#discussion_r1904887081

From dholmes at openjdk.org  Tue Jan  7 04:43:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 04:43:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
Message-ID: <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>

On Mon, 6 Jan 2025 19:19:23 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still be used. 

Yeah good catch. I just find it frustrating that we already have so many initialization-progress markers but we are looking at adding yet-another-one. Also I'm not sure this is really relevant to mutex itself per-se it is rather about whether mutexes are needed - to that end I don't find `Threads::is_single_threaded() ` a terrible suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2574379871

From lmesnik at openjdk.org  Tue Jan  7 04:48:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 7 Jan 2025 04:48:35 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <iimUmbOmazgEuv-W28OEWjUP04nUPhNnFlcPijwXgEk=.16451a10-d1ad-4a1a-8093-dc717edffd4b@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
 <iimUmbOmazgEuv-W28OEWjUP04nUPhNnFlcPijwXgEk=.16451a10-d1ad-4a1a-8093-dc717edffd4b@github.com>
Message-ID: <OqbBwSF7_1vvdbl25pCQw6m5QooR0jrc7TVbMSEbwXY=.c4cb1719-8419-4a9d-afd4-26e4ecae6f6e@github.com>

On Tue, 7 Jan 2025 04:19:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
>> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.
>> 
>> Verified that it pass now with CDS off with and without UseCompactObjectHeaders.
>> 
>> I removed also other heap limits just because they are not needed and only might confuse test readers.
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java line 43:
> 
>> 41:  *      -agentlib:resexhausted=-waittime=5
>> 42:  *      -Xms64m
>> 43:  *      -Xmx64m
> 
> Don't you need these to ensure we get OOME in a reasonable amount of time on systems with huge memories?

The test trigger OOME in Metaspace only by loading classes, so heap shouldn't be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22936#discussion_r1904900729

From dholmes at openjdk.org  Tue Jan  7 05:14:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 05:14:43 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
Message-ID: <yVC5vLS2Vu-SIDEck4PFlOkxkvRyU4Iqp2Opf-1tlFc=.2c8e5b0a-49e3-4467-902d-eb84bc5f2179@github.com>

On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.
> 
> Verified that it pass now with CDS off with and without UseCompactObjectHeaders.
> 
> I removed also other heap limits just because they are not needed and only might confuse test readers.

Changes seem fine.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22936#pullrequestreview-2533398021

From dholmes at openjdk.org  Tue Jan  7 05:14:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Jan 2025 05:14:44 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <OqbBwSF7_1vvdbl25pCQw6m5QooR0jrc7TVbMSEbwXY=.c4cb1719-8419-4a9d-afd4-26e4ecae6f6e@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
 <iimUmbOmazgEuv-W28OEWjUP04nUPhNnFlcPijwXgEk=.16451a10-d1ad-4a1a-8093-dc717edffd4b@github.com>
 <OqbBwSF7_1vvdbl25pCQw6m5QooR0jrc7TVbMSEbwXY=.c4cb1719-8419-4a9d-afd4-26e4ecae6f6e@github.com>
Message-ID: <dVYg32X7g2sqOXTuN8PotmiuSApBGPjcIL27lFKOO4o=.3da4d150-fadd-4be4-84e4-5b1da7474ac7@github.com>

On Tue, 7 Jan 2025 04:46:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java line 43:
>> 
>>> 41:  *      -agentlib:resexhausted=-waittime=5
>>> 42:  *      -Xms64m
>>> 43:  *      -Xmx64m
>> 
>> Don't you need these to ensure we get OOME in a reasonable amount of time on systems with huge memories?
>
> The test trigger OOME in Metaspace only by loading classes, so heap shouldn't be used.

Ah I see.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22936#discussion_r1904914292

From sspitsyn at openjdk.org  Tue Jan  7 05:57:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 05:57:40 GMT
Subject: RFR: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
Message-ID: <NCPK1SSw9p4OIDR1LCtQ8KGYjoLVmMvxPsDhq4OHsK0=.35860321-4e17-49da-8ffd-a10509eced7e@github.com>

On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.
> 
> Verified that it pass now with CDS off with and without UseCompactObjectHeaders.
> 
> I removed also other heap limits just because they are not needed and only might confuse test readers.

LGTM

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22936#pullrequestreview-2533438403

From vlivanov at openjdk.org  Tue Jan  7 06:13:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Jan 2025 06:13:48 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v11]
In-Reply-To: <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <ddvv9o9G1i4sIiN_4T9AVEpDX0TC1lpdKvYZ1QGMQTI=.131f5ad2-0aa4-46ac-8077-b67b6c6a6eff@github.com>
 <8UJ0xv2YRkXDMkD05IxpRA-_CmGa2K_14YB3ZMawwAE=.274408f1-f47b-4d45-bf90-d66915291f2f@github.com>
 <kz-6hL6KLP6tRXZWVBrhM5d3cOXmx5GhJOTqDpLR6po=.37fedf6e-85de-4553-b2cc-b1862b01e896@github.com>
 <iPmg1WAKVjyUS87dsewJWb5nsEOkb5RelyO1O5Q7qn8=.bf2049d0-4fae-4364-91c7-463acdeefc5c@github.com>
Message-ID: <Mzfi_xXZcz9uycuSgiIdkk42MB-oMgUY1d8qg0G0SSc=.b13cec7d-a742-4934-b393-13f31c01d191@github.com>

On Mon, 6 Jan 2025 13:47:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, we are.
>
> I had a little experiment.
> 
> extern "C" int printf(const char *,...);
> int main() {
>   unsigned short ss = 0x8000;
>   printf("does unsigned sign extend to int? %d\n", int(ss));
> }

IMO you could just call `as_int()` here. All other usages of `ciFlags::as_int()` are in printing code. 

Ideally, `ciField::print()` could use `ciFlags::print()`, but such cleanup can be done separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1904950560

From vlivanov at openjdk.org  Tue Jan  7 06:13:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 7 Jan 2025 06:13:48 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <rm5SvqORaYvN5ulwdWzJYyZQn0NxO_EPZ0XMiLX3WKU=.4c834cf7-8195-49fd-882b-f68c0a0605ad@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2533455739

From rsunderbabu at openjdk.org  Tue Jan  7 08:04:11 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 7 Jan 2025 08:04:11 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests
Message-ID: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>

Trivial logging message change.

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

Commit messages:
 - trivial logging change

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

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

From rsunderbabu at openjdk.org  Tue Jan  7 08:04:11 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 7 Jan 2025 08:04:11 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests
In-Reply-To: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
Message-ID: <VgxodpZ3tG1aXopImTS5amsKFlQxRWm3sB-VI6Ex4Yg=.95e463e9-535c-40a5-910c-ff4bc8d83c5c@github.com>

On Tue, 7 Jan 2025 07:58:18 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Trivial logging message change.

Sanity testing done.

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

PR Comment: https://git.openjdk.org/jdk/pull/22939#issuecomment-2574615336

From kbarrett at openjdk.org  Tue Jan  7 08:34:41 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
Message-ID: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>

On Mon, 6 Jan 2025 15:04:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/ageTable.cpp line 38:
>> 
>>> 36: #include "logging/logStream.hpp"
>>> 37: 
>>> 38: /* Copyright (c) 1992, 2025, Oracle and/or its affiliates, and Stanford University.
>> 
>> Well this is weird.  An atypical copyright down inside the file?
>
> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.

Not sure we're allowed to remove a copyright statement, even if not in the usual place.

>> test/hotspot/gtest/utilities/test_globalDefinitions.cpp line 281:
>> 
>>> 279: 
>>> 280:   check_format("%zd",                  (intx)123,         "123");
>>> 281:   check_format("0x%zx",                (intx)0x123,       "0x123");
>> 
>> Could be "%#zx".
>
> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?

I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
prefix gets included in the width when dealing with field width, which might not be great either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905081061
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905079637

From kbarrett at openjdk.org  Tue Jan  7 08:34:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:34:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
Message-ID: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>

On Mon, 6 Jan 2025 15:21:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I have to confess that I have no idea what this is trying to show.  I'd rather have all the UINTX_FORMAT purged and not leave a remnant for these two special cases.  A function whose name describes what this is trying to show would be better.
>
> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.

I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
format directives that resemble line noise, or ugly conditionals like that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905076840

From kbarrett at openjdk.org  Tue Jan  7 08:52:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:42 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
Message-ID: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>

On Tue, 7 Jan 2025 08:28:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @theRealAph added this with the secondary super cache work, but I think it may have also been meant to be zx because of the leading 0x.  So INTPTR_FORMAT would also work.
>
> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
> format directives that resemble line noise, or ugly conditionals like that.

Improving on my prior suggestion
`"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
But still looking a lot like line noise, and still think it shouldn't be changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905101674

From kbarrett at openjdk.org  Tue Jan  7 08:52:43 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 7 Jan 2025 08:52:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>

On Tue, 7 Jan 2025 08:31:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I fixed this.  This seems ok.  I didn't know about this format option tbh but if it's standard, why not?
>
> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
> prefix gets included in the width when dealing with field width, which might not be great either.

The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
rather than field width.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905104428

From yasuenag at gmail.com  Tue Jan  7 09:30:02 2025
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 7 Jan 2025 18:30:02 +0900
Subject: [External] : Alternative to sadebugd
In-Reply-To: <SN7PR10MB70328CEFF18AF35148CB3AB297102@SN7PR10MB7032.namprd10.prod.outlook.com>
References: <44818014-55cf-4e3f-aef0-96950c8b1cd5@gmail.com>
 <SN7PR10MB70328CEFF18AF35148CB3AB297102@SN7PR10MB7032.namprd10.prod.outlook.com>
Message-ID: <ae6b7039-9976-44b7-8148-cb7bd3aaf63b@gmail.com>

Hi Kevin, all,

> If there is any resistance or reason not to do this in the JDK, then I guess it's something that does not absolutely have to be in the JDK itself.  A proxy-like tool that is outside the JDK can work.

I believe we have an use case what I shown at least even though it might not use frequently. So I want to keep remote debugging feature.
I think we can take following options for remote debugging:


1. Adapter for GDB Server
    GDB provides gdbserver for remote debugging. We can leverage GDB and its wire protocols for remote debugging.
    Volume of codes might not be different from current RMI implementation because we need to make Java/JVM related codes in scratch.

2. Plugin API for SA
    Publish SA API for developers. The developer who want to create their own debug facility implements JVMDebugger like RemoteDebuggerClient.
    SA would load it dynamically if user specifies, and use it in debug session.


IMO it is better 2 because I guess we can expose some classes from jdk.hotspot.agent module with little changes. It is much better if we can provide HTTP client as an example.


Thanks,

Yasumasa


On 2025/01/07 2:21, Kevin Walls wrote:
> Hi -
> 
> I created JDK-8340121 to have the actual removal of RMI features visible... on the horizon somewhere... I did not mean to suggest it is going away very very soon.  I don't want to make a forward-looking statement or a promise, but I do not expect this to be acted on right now.  But I also don't want us to forget the idea of removing it in future.
> 
> Will need to look at your idea in more detail.
> 
> If there is any resistance or reason not to do this in the JDK, then I guess it's something that does not absolutely have to be in the JDK itself.  A proxy-like tool that is outside the JDK can work.  Yes it is likely more convenient to use if it's bundled in the JDK, but we would need to balance that convenience for some users with any ongoing maintenance etc for others.
> 
> Thanks
> Kevin
> 
> 
> -----Original Message-----
> From: Yasumasa Suenaga <yasuenag at gmail.com>
> Sent: Thursday, January 2, 2025 1:12 PM
> To: serviceability-dev at openjdk.org
> Cc: Yasumasa Suenaga <suenaga at oss.nttdata.com>; Kevin Walls <kevin.walls at oracle.com>
> Subject: [External] : Alternative to sadebugd
> 
> Hi all,
> 
> sadebugd and related options in jhsdb have been deprecated by JDK-8338894 since JDK 24. I agree with RMI removal from SA, but I'd like to keep remote debugger feature for some cases.
> 
> For example, sadebugd can be used to debug in distroless container on Kubernetes. As you know distroless container does not have any shell, and also no JDK tools including jhsdb. If we want to analyze hang-up'ed JVM in it with HSDB, we have to attach ephemeral container and expose the port for debugging to connect from HSDB.
> I talked about use case of jhsdb debugd on Kubernetes (in Japanese...) https://urldefense.com/v3/__https://www.youtube.com/watch?v=5evMwwPUl14&t=346s__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQRGV_0QBQ$
> 
> So I want to alternative it to HTTP:
>     https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...YaSuenag:jdk:http-sadebugd__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQQf3ZTEeQ$
> 
> This change works with some CLHSDB commands (jstack, findsym at least). Note that it has some errors and does not have some implementations and test cases.
> 
> You can use this following command:
> 
>     Server: jhsdb httpserver --host testhost --port 8080 --pid <PID>
>     Client: jhsdb clhsdb --httpconnect https://urldefense.com/v3/__http://testhost:8080/__;!!ACWV5N9M2RV99hQ!NuxD4yot2sGNRM2ovu1uXExdmfovb9hK4Vsy0eFNRgniGUI1ElO6gzPaEx2Q6Btqs5c9rA57DQQeBBszCA$
> 
> This change transports debugging data on HTTP. We can set reverse proxy (for HTTPS endpoint and/or authentication) for secure connection if need.
> 
> 
> Remote debugging removal has been filed as JDK-8340121. It does not seem to be targeted, but the work might be started soon. So I'd like to make alternatives by then.
> 
> What do you think?
> 
> 
> Thanks,
> 
> Yasumasa


From coleenp at openjdk.org  Tue Jan  7 12:36:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:36:46 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
 <esnDP-9AzRwztBz2v7Eu_ndX6yU652c8SJQ8we_-NLg=.995481e6-6751-4501-9fee-dc6c0c228934@github.com>
Message-ID: <ThBA0Kns0IoLwZ4OkKm5X_oh5WJKcgGn_AV610Xhhyo=.c65e531d-5c24-438d-8b09-498f40235f6e@github.com>

On Tue, 7 Jan 2025 08:50:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I'd forgotten about that format option too, which is why I'm not enamored of it.  Also, written that way the
>> prefix gets included in the width when dealing with field width, which might not be great either.
>
> The problem of accounting for the prefix in the field width calculation can be dealt with by using precision
> rather than field width.

Well then that leaves the fun of dealing with these format specifiers when you're trying to do your own formatting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905390045

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Restore copyright and macro.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/6e8b2702..ae9d9f6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22916&range=03-04

  Stats: 8 lines in 4 files changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22916.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22916/head:pull/22916

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

From coleenp at openjdk.org  Tue Jan  7 12:51:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 12:51:33 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <sHOrTz3gjuITrSguiSPwYR2Ou1EVLlYbsA79tY00_QI=.438cf8de-c088-4ae2-857c-f62bb14c7dd4@github.com>
 <dnZzf-LrqQeN4j0iI0AcQVPW78D0sdgsfqPbP2w8TAc=.c19dcc92-d078-4b77-a8d2-b6342283842c@github.com>
 <BuoklO2QXoFY_QGV-XGSIyx1fjKDzvfAIKnSX23voB4=.32964bc7-a214-4ee4-9925-b327aa900c8f@github.com>
Message-ID: <L3cRMsD-8R7vI4fAvbYGrkjq6xEOrpjvrMMIGjZboFY=.67be8877-242a-47c9-b224-5829ce85eab7@github.com>

On Tue, 7 Jan 2025 08:48:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I don't think we should be mixing uintx types and UINTPTR_FORMAT like that.  As I said earlier, this is one that
>> I think probably ought not be changed at all.  I think some of the FORMAT macros are useful to avoid inline
>> format directives that resemble line noise, or ugly conditionals like that.
>
> Improving on my prior suggestion
> `"%#.*zx", (2 * BytesPerWord), _secondary_supers_bitmap`
> Using precision rather than field width, to avoid needing to account for the prefix in the width calculation.
> But still looking a lot like line noise, and still think it shouldn't be changed.

Yes, this looks horrible.  The macro that I was trying to remove is better.  I restored but moved it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1905405696

From yzheng at openjdk.org  Tue Jan  7 16:17:45 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Tue, 7 Jan 2025 16:17:45 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <8DdLbSa2qunYTvNQxss7Dh26pYhGzZepTCgE1252_VI=.0150a509-d248-43a5-a01b-f47a96589727@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

JVMCI changes look good to me!

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2534792137

From sspitsyn at openjdk.org  Tue Jan  7 19:39:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:39:16 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v8]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <zq4IECS1_2qX3FChMHDYwM6pbzDB4JdPZ0JkL3JZMxs=.41c7e626-6f54-433c-826f-c45afb6c58d7@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge
 - review: updated one copyright year
 - review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp
 - review: removed unneeded check for JvmtiExport::can_post_frame_pop()
 - review: add a unit test covering JVMTI ClearAllFramePops
 - review: removed DUPLICATE related changes; a minor tweak for ASSERT line
 - added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
 - fixed trailing space in jvmtiEnvBase.hpp
 - 8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/21ca5294..6a8e37aa

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

  Stats: 21029 lines in 649 files changed: 15125 ins; 3706 del; 2198 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

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

From sspitsyn at openjdk.org  Tue Jan  7 19:39:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:39:26 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v5]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <7KIxNpNeQdzrpTAfDoFJCMI1Eb3KYCSS1RaSsqZrCrg=.f3789314-03cc-46ba-bd76-90edd8ee6685@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge
 - review: improved one failure logging a little bit
 - review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned
 - review: minor tweak in jvmti.xml update
 - 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/2b3fef1e..2468357f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=03-04

  Stats: 21029 lines in 649 files changed: 15125 ins; 3706 del; 2198 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

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

From sspitsyn at openjdk.org  Tue Jan  7 19:47:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:47:10 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v6]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/2468357f..fbf9459d

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

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

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

From sspitsyn at openjdk.org  Tue Jan  7 19:53:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 19:53:20 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v9]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  update ciopyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/6a8e37aa..4682bcba

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

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

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

From sspitsyn at openjdk.org  Tue Jan  7 20:21:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 20:21:38 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <8JJQFQfpJBAwdH9AWlW037NoiFt99uxqXadqVOGRnOQ=.603d82b0-f3f4-4c1d-a957-30f88acf1676@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

Patricio, please, let me double check something before your push.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2576149281

From sspitsyn at openjdk.org  Tue Jan  7 20:26:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 7 Jan 2025 20:26:41 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <WvirHJ0p51sW319n_lz1Mgv4bcq4L2GhMcizCe-jYwo=.134f1180-969b-4b33-b131-2829e2e94f51@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Thank you for one more unification update! Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2535297355

From dlong at openjdk.org  Tue Jan  7 21:02:19 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 21:02:19 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

src/hotspot/share/classfile/vmIntrinsics.cpp line 39:

> 37: 
> 38: // These are flag-matching functions:
> 39: inline bool match_F_R(u2 flags) {

I wish more code could be size-agnostic.  So instead of using `u2` here, there could be a typedef in accessFlags.hpp that we could use that hides the size.  However, it's not a big deal, because it seems unlikely this type will change much in the future without a JVM spec change.  I'm tempted to suggesting using AccessFlags here, but it's a class.  Since this is an end-point "consumer" of the type that doesn't store it or pass it along, we could even use something like `uint` here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1906033152

From dlong at openjdk.org  Tue Jan  7 21:23:37 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 7 Jan 2025 21:23:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <oJJ4G2eUKrl3s_ZXA2Incjej0gjUgjJfBHK9We1zQvI=.bedeea70-55c1-4dae-a52d-c6e5deebfe59@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

Marked as reviewed by dlong (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2535389245

From coleenp at openjdk.org  Tue Jan  7 22:06:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:42 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
Message-ID: <XbcOXVEWmXamhjuakfCSR6xjdLkz-MuzR_yAtF-TH4M=.b01e080e-72d3-49f0-8bc3-4a6c3c0a5175@github.com>

On Tue, 7 Jan 2025 02:36:36 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.

> IMO you could just call as_int() here. All other usages of ciFlags::as_int() are in printing code.
> Ideally, ciField::print() could use ciFlags::print(), but such cleanup can be done separately.

This does seem like a good future cleanup.  Thanks for reviewing Vladimir.

Thanks for reviewing David, Yudi and Serguei.  I reran tiers 1-7 on this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2576308012
PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2576309500

From coleenp at openjdk.org  Tue Jan  7 22:06:43 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v13]
In-Reply-To: <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <n3CvZ5Bhfq-oBuIUuy-zZNdBj25e4dcmim_RqHqd-B8=.32c4044d-a07e-400f-b25e-f1cb7b606b5c@github.com>
 <4DemtiMYMfFk02L_CpRut0MMGssK3jBcKfSTMLH36Y4=.24ee458f-5893-4249-b166-496f04a35d70@github.com>
Message-ID: <c26HPTNYT_1LUt7TbuVfGmc7zyMZX2WrphfyaotBi58=.7f660db3-831c-45b5-8f16-beadea6b5b86@github.com>

On Tue, 7 Jan 2025 20:59:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make more AccessFlags fetches more specific and remove an assert and remove this->s.
>
> src/hotspot/share/classfile/vmIntrinsics.cpp line 39:
> 
>> 37: 
>> 38: // These are flag-matching functions:
>> 39: inline bool match_F_R(u2 flags) {
> 
> I wish more code could be size-agnostic.  So instead of using `u2` here, there could be a typedef in accessFlags.hpp that we could use that hides the size.  However, it's not a big deal, because it seems unlikely this type will change much in the future without a JVM spec change.  I'm tempted to suggesting using AccessFlags here, but it's a class.  Since this is an end-point "consumer" of the type that doesn't store it or pass it along, we could even use something like `uint` here.

That seems like a good idea if this weren't so limited.  I did chat with DanH. to see if access flags will ever grow in size from u2 and he was doubtful that would ever happen. uint would work here too, but this small use might prevent some future -Wconversion warnings and doesn't hurt anything.
Thank you for reviewing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1906090983

From coleenp at openjdk.org  Tue Jan  7 22:06:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 7 Jan 2025 22:06:44 GMT
Subject: Integrated: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <hiPoyjk4Lj9wjmzLyIMWoFHmk5nMiQtgNEIAHuTxDb8=.8f60692f-e2d3-42ca-9a8a-90cc2bf17228@github.com>

On Tue, 19 Nov 2024 16:18:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

This pull request has now been integrated.

Changeset: 098afc8b
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/098afc8b7d0e7caa82999fb9d4e319ea8aed09a1
Stats:     328 lines in 58 files changed: 45 ins; 50 del; 233 mod

8339113: AccessFlags can be u2 in metadata

Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: sspitsyn, vlivanov, yzheng, dlong, dholmes

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

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

From dholmes at openjdk.org  Wed Jan  8 00:10:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:10:20 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
Message-ID: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>

Revert "8339113: AccessFlags can be u2 in metadata"

This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.

The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.

Thanks

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

Commit messages:
 - Revert "8339113: AccessFlags can be u2 in metadata"

Changes: https://git.openjdk.org/jdk/pull/22959/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22959&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347148
  Stats: 328 lines in 58 files changed: 50 ins; 45 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/22959.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22959/head:pull/22959

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

From coleenp at openjdk.org  Wed Jan  8 00:12:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 00:12:44 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
Message-ID: <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>

On Wed, 8 Jan 2025 00:04:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8339113: AccessFlags can be u2 in metadata"
> 
> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
> 
> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
> 
> Thanks

Looks good plus urgent.  Thanks for doing this, David.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22959#pullrequestreview-2535594292

From dholmes at openjdk.org  Wed Jan  8 00:18:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:18:34 GMT
Subject: RFR: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
 <x8vRQQTfYQ16EC0IedEe6hKfvS0aEjgmZ6Nv-vX6cVE=.47766884-6ce0-4c41-a41c-f6eeddc2e623@github.com>
Message-ID: <KiVUwU3baOLFdE6LOix3Xw0yfY-_Rp4Kt2L4zyzBh8s=.e6ed9ef9-ae1f-4c04-b6b9-100e9a45cd14@github.com>

On Wed, 8 Jan 2025 00:10:25 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Revert "8339113: AccessFlags can be u2 in metadata"
>> 
>> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
>> 
>> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
>> 
>> Thanks
>
> Looks good plus urgent.  Thanks for doing this, David.

Thanks for the review @coleenp ! Just waiting tier1 sanity to complete

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

PR Comment: https://git.openjdk.org/jdk/pull/22959#issuecomment-2576463303

From dholmes at openjdk.org  Wed Jan  8 00:42:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 00:42:38 GMT
Subject: Integrated: 8347148: [BACKOUT]  AccessFlags can be u2 in metadata
In-Reply-To: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
References: <8nNvTk0YI5WeE9zzHt5NkoIdW0J5OfxFabGVNVN2saM=.fadfb990-0d5d-4e14-9989-10c422a03ac1@github.com>
Message-ID: <9o7YHNAv4mkotoVPqwxDgL_-s1CN9UCrrIihsBVe89o=.b6337941-8549-433d-bda2-fb42c6e5b112@github.com>

On Wed, 8 Jan 2025 00:04:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8339113: AccessFlags can be u2 in metadata"
> 
> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
> 
> The integration of the original change needs to be coordinated with a change to Graal so backing out till that is ready.
> 
> Thanks

This pull request has now been integrated.

Changeset: 021c4764
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/021c476409c52c65cc7b40516d81dedef040fe83
Stats:     328 lines in 58 files changed: 50 ins; 45 del; 233 mod

8347148: [BACKOUT]  AccessFlags can be u2 in metadata

Reviewed-by: coleenp

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

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

From sspitsyn at openjdk.org  Wed Jan  8 05:38:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Jan 2025 05:38:45 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

The fix looks good. It is a great and important finding - thanks!
What was bothering me is that the `EnterInterpOnlyModeClosure` is used in the `JvmtiEventControllerPrivate::enter_interp_only_mode()` but no `HandshakeClosure` is used in the `JvmtiEventControllerPrivate::leave_interp_only_mode()`. The handshake use for the `enter_interp_only_mode()` looks like a paranoid overkill to me. It can be I just forgot the exact reason why it is used there.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22931#pullrequestreview-2536049299

From dholmes at openjdk.org  Wed Jan  8 05:54:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 8 Jan 2025 05:54:36 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests
In-Reply-To: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
Message-ID: <yZFuZr_1vTxPbEXGiouaJZ5fGlNk2_7Qk7fJRc2GDZA=.e1f115c5-72c8-4978-b54c-2b865c866e12@github.com>

On Tue, 7 Jan 2025 07:58:18 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Trivial logging message change.

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2024, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001.java line 65:

> 63:             }
> 64: 
> 65:             System.out.println("Can't reproduce OOME due to a limit on iterations/execution time. resexhausted001 Test was useless."

Suggestion:

            System.out.println("Test resexhausted001: Can't reproduce OOME due to a limit on iterations/execution time. Test was useless."

This format reads somewhat better to me.

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

PR Review: https://git.openjdk.org/jdk/pull/22939#pullrequestreview-2536062199
PR Review Comment: https://git.openjdk.org/jdk/pull/22939#discussion_r1906510965
PR Review Comment: https://git.openjdk.org/jdk/pull/22939#discussion_r1906512847

From cjplummer at openjdk.org  Wed Jan  8 07:28:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 07:28:07 GMT
Subject: RFR: 8347162: Update problemlist CR for
 vmTestbase/nsk/jdi/VMOutOfMemoryException
Message-ID: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>

Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list entry needs to be updated.

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

Commit messages:
 - Update CR for VMOutOfMemoryException problem list entry

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

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

From rsunderbabu at openjdk.org  Wed Jan  8 07:45:24 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 8 Jan 2025 07:45:24 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
Message-ID: <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>

> Trivial logging message change.

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  incorporated review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22939/files
  - new: https://git.openjdk.org/jdk/pull/22939/files/69071c5e..28c1b8ea

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

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

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

From rsunderbabu at openjdk.org  Wed Jan  8 07:45:24 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 8 Jan 2025 07:45:24 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <yZFuZr_1vTxPbEXGiouaJZ5fGlNk2_7Qk7fJRc2GDZA=.e1f115c5-72c8-4978-b54c-2b865c866e12@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
 <yZFuZr_1vTxPbEXGiouaJZ5fGlNk2_7Qk7fJRc2GDZA=.e1f115c5-72c8-4978-b54c-2b865c866e12@github.com>
Message-ID: <fIJVtn4tYmkeLPEWKBDnNZyIDjxS8xdK03AyTnXTWHE=.10e30ce4-648a-42be-af92-db3558d99741@github.com>

On Wed, 8 Jan 2025 05:48:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   incorporated review comments
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Suggestion:
> 
>  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.

subconsciously still in vacation, I guess. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22939#discussion_r1906619398

From sspitsyn at openjdk.org  Wed Jan  8 09:12:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Jan 2025 09:12:41 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
 <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
Message-ID: <vYUkOCekx_arECHLewSAnQl7ldvawZK0fwX1xO1DRCY=.830e2713-55ce-4dde-89c6-5db1a0a1ed7a@github.com>

On Wed, 8 Jan 2025 07:45:24 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Trivial logging message change.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporated review comments

It looks okay with the suggestion from David.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22939#pullrequestreview-2536581033

From coleenp at openjdk.org  Wed Jan  8 13:43:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 13:43:52 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata
Message-ID: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>

This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.

A tier1 sanity test in progress.

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

Commit messages:
 - 8347147: [REDO] AccessFlags can be u2 in metadata

Changes: https://git.openjdk.org/jdk/pull/22968/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22968&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347147
  Stats: 328 lines in 58 files changed: 45 ins; 50 del; 233 mod
  Patch: https://git.openjdk.org/jdk/pull/22968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22968/head:pull/22968

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

From kevinw at openjdk.org  Wed Jan  8 14:18:36 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 8 Jan 2025 14:18:36 GMT
Subject: RFR: 8347162: Update problemlist CR for
 vmTestbase/nsk/jdi/VMOutOfMemoryException
In-Reply-To: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
References: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
Message-ID: <xwAO38ND4wevHm94Ew5lK3bpXyNcpLcubAbZUzwloUk=.e0cda748-2dd0-4eeb-9aa6-fc628e27c736@github.com>

On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list entry needs to be updated.

Looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22960#pullrequestreview-2537268738

From coleenp at openjdk.org  Wed Jan  8 14:49:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 14:49:35 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <7NzZ7Lj7Aapsnt9zTgcJ7KUzLWNHNiskGiePGkpQIxU=.7c6779dd-6194-4a20-a598-c65bffff1c89@github.com>

On Wed, 8 Jan 2025 13:38:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

PR for original review here: https://github.com/openjdk/jdk/pull/22246

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

PR Comment: https://git.openjdk.org/jdk/pull/22968#issuecomment-2577853778

From duke at openjdk.org  Wed Jan  8 16:38:50 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 8 Jan 2025 16:38:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v13]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  use Threads::is_single_threaded()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/5e36546e..379eaac8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=11-12

  Stats: 38 lines in 7 files changed: 15 ins; 17 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

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

From coleenp at openjdk.org  Wed Jan  8 16:40:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 16:40:59 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v2]
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <8tNmyDP0TIeRCdxsXomkLvU5Xqq3ACegEUHDPe-jPSc=.df292c1b-f901-4068-8915-c501d4ee8ab1@github.com>

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix some more triggerUnloading() in tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22968/files
  - new: https://git.openjdk.org/jdk/pull/22968/files/71419187..9b2abf9c

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

  Stats: 13 lines in 3 files changed: 5 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22968/head:pull/22968

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

From coleenp at openjdk.org  Wed Jan  8 16:43:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 16:43:51 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:

  8347147: [REDO] AccessFlags can be u2 in metadata

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22968/files
  - new: https://git.openjdk.org/jdk/pull/22968/files/9b2abf9c..71419187

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

  Stats: 13 lines in 3 files changed: 0 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22968.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22968/head:pull/22968

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

From pchilanomate at openjdk.org  Wed Jan  8 17:35:41 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 17:35:41 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
Message-ID: <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>

On Wed, 8 Jan 2025 05:35:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks good. It is a great and important finding - thanks! What was bothering me is that the `EnterInterpOnlyModeClosure` is used in the `JvmtiEventControllerPrivate::enter_interp_only_mode()` but no `HandshakeClosure` is used in the `JvmtiEventControllerPrivate::leave_interp_only_mode()`. The handshake use for the `enter_interp_only_mode()` looks like a paranoid overkill to me. It can be I just forgot the exact reason why it is used there.
>
I see. Yes, we still need the handshake in `JvmtiEventControllerPrivate::enter_interp_only_mode` to safely walk the stack of the target to deoptimize the frames. When leaving interpreter only mode we just decrement `_interp_only_mode/_saved_interp_only_mode` so I don?t think we need anything else, other than making sure the change is atomic, which I think we guarantee by holding `JvmtiThreadState_lock`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2578238579

From stooke at openjdk.org  Wed Jan  8 18:01:27 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 8 Jan 2025 18:01:27 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v3]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <VMnZyQk__1dIZurrIBbYdzU9nKyN61pSWUWpPpsHco4=.e5b19d2f-4b29-4527-9f89-140502c2cec8@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into pr_8346717
 - refine jtreg tags per review
 - Merge branch 'pr_8346717' of https://github.com/stooke/jdk into pr_8346717
 - restore deleted function name
 - add ZGC run of SystemMapTest
 - fix test for unready thread on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/9819f027..f47f9425

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

  Stats: 17637 lines in 241 files changed: 6043 ins; 10628 del; 966 mod
  Patch: https://git.openjdk.org/jdk/pull/22870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22870/head:pull/22870

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

From amenkov at openjdk.org  Wed Jan  8 18:10:40 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 8 Jan 2025 18:10:40 GMT
Subject: RFR: 8347162: Update problemlist CR for
 vmTestbase/nsk/jdi/VMOutOfMemoryException
In-Reply-To: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
References: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
Message-ID: <p8Z7OAQ6g49XYBqcAgkOC-xNhC6e-HOpbY_TTVW2D80=.19c12493-bd37-4a93-8fe6-8afb094d8c4b@github.com>

On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list entry needs to be updated.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22960#pullrequestreview-2537847120

From vlivanov at openjdk.org  Wed Jan  8 19:17:11 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 8 Jan 2025 19:17:11 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <cWy9x1rHhncmchshDYO9u2399BaiharSu2GcJdftHrw=.d583f27f-ef48-4590-b6fd-922558ec9b23@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Reviewed.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22968#pullrequestreview-2537996774

From yzheng at openjdk.org  Wed Jan  8 19:50:44 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 8 Jan 2025 19:50:44 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <Dq3Dxp2sgPWU0T7IipaXNwgjzfxGCjD9LydU24o9ExI=.ac5cc352-67ef-4638-ba5a-f599e390a44d@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Marked as reviewed by yzheng (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22968#pullrequestreview-2538071009

From coleenp at openjdk.org  Wed Jan  8 19:50:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 19:50:44 GMT
Subject: RFR: 8347147: [REDO] AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
 <3FLD6UOms5vFKQ7Mkm61hJrSBlppwtY5IwZo40Vyly8=.1070a4eb-ecc4-4158-9c32-0982dd8612ed@github.com>
Message-ID: <GDiLKcqwNaKTAQSDnM8C0OuxTkr1yScHwYTN83_-2Ps=.f3f8b239-72e4-4438-958b-7eebd6da337f@github.com>

On Wed, 8 Jan 2025 16:43:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
>> 
>> A tier1 sanity test complete.
>
> Coleen Phillimore has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains one commit:
> 
>   8347147: [REDO] AccessFlags can be u2 in metadata

Thank you for the re-review Vladimir and Yudi.

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

PR Comment: https://git.openjdk.org/jdk/pull/22968#issuecomment-2578500217

From coleenp at openjdk.org  Wed Jan  8 19:50:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 8 Jan 2025 19:50:45 GMT
Subject: Integrated: 8347147: [REDO] AccessFlags can be u2 in metadata
In-Reply-To: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
References: <YO_3WosNFCvfNdr_IzfoAlgfU2Z-YuEUYbSgPOXmiEk=.581fabc2-609e-4e46-9ea3-194fae5c8c19@github.com>
Message-ID: <tJrtkuZoPY8e5_JsEilAHfsQ9NfOhRlaE6GwJaEIMts=.335092d5-7b53-4416-845e-bb1fa25fa3e9@github.com>

On Wed, 8 Jan 2025 13:38:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is the same change that I pushed as commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1 but now coordinated with @mur47x111  for the graal changes.
> 
> A tier1 sanity test complete.

This pull request has now been integrated.

Changeset: 6ee2bd2f
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ee2bd2f33e38c13f93fba9953b33850828d031b
Stats:     328 lines in 58 files changed: 45 ins; 50 del; 233 mod

8347147: [REDO] AccessFlags can be u2 in metadata

Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: vlivanov, yzheng

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

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

From lmesnik at openjdk.org  Wed Jan  8 20:29:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 8 Jan 2025 20:29:41 GMT
Subject: Integrated: 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003
 fails with java.lang.OutOfMemoryError when CDS is off
In-Reply-To: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
References: <t7I2Ev4k8KeJUf7o0-xayvMP35J8vHcDDWDiPxGypiw=.4d2c1370-463f-4c2f-a125-98387d6eefb4@github.com>
Message-ID: <AWAdhk_hek0GpLwlRqqFlZ5D5odxV1im3kstUzE-bXc=.3d480fb6-04bb-43cc-868b-e1c629dc0358@github.com>

On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test nsk/jvmti/ResourceExhausted/resexhausted003  limits metaspace size. 9m is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives are no built  this mode.  Never executed with CDS off before.
> 
> Verified that it pass now with CDS off with and without UseCompactObjectHeaders.
> 
> I removed also other heap limits just because they are not needed and only might confuse test readers.

This pull request has now been integrated.

Changeset: 88fa3b2f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88fa3b2fe9bccf9cd4a4041732e2f6d425c19244
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003 fails with java.lang.OutOfMemoryError when CDS is off

Reviewed-by: dholmes, sspitsyn

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

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

From hannesw at openjdk.org  Wed Jan  8 20:30:11 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 8 Jan 2025 20:30:11 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules
Message-ID: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>

Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.

[JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931

For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 

Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

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

Commit messages:
 - 8347123: Add missing @serial tags to other modules

Changes: https://git.openjdk.org/jdk/pull/22980/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22980&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347123
  Stats: 107 lines in 39 files changed: 45 ins; 0 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/22980.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22980/head:pull/22980

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

From stooke at openjdk.org  Wed Jan  8 21:01:37 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 8 Jan 2025 21:01:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  test SystemMap with and without ZGC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/f47f9425..f62bbd7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=02-03

  Stats: 11 lines in 1 file changed: 1 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22870/head:pull/22870

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

From pchilanomate at openjdk.org  Wed Jan  8 21:53:40 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 21:53:40 GMT
Subject: Integrated: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
Message-ID: <2TkKI1RXg3EHYgTYkbqhzKfSc2l_7MLkhRcfq5i7AJQ=.81986a22-37da-41e6-bafb-d8870b74e50d@github.com>

On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: ea495377
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8310340: assert(_thread->is_interp_only_mode() || stub_caller) failed: expected a stub-caller

Reviewed-by: dholmes, amenkov, sspitsyn

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

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

From pchilanomate at openjdk.org  Wed Jan  8 21:53:39 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 8 Jan 2025 21:53:39 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <txGcUNxJa5bkZiI8TOKjaTPY02FVBbXXd27l9X7IDeg=.5958522a-4bed-4faa-b452-0e6ab63093aa@github.com>
Message-ID: <pNm0Hb8o37byfoPkSUet9Qxaz53BO7GNBEpD6W-OEDg=.15866a6a-b99e-48d7-ab01-5005399bf79e@github.com>

On Mon, 6 Jan 2025 21:20:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review the following fix. In method `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to call `leave_interp_only_mode()` for the case where `should_be_interp` is computed as false and `state->is_pending_interp_only_mode()` is true. I added the full trace leading to the crash in the bug comments.
>> In JDK-8338383 I removed this assert because the branch condition changed and it became sort of a redundant check. But given that it was able to find this issue I added it back.
>> I was able to reproduce the crash easily by adding an extra delay before the assert. I verified the crash doesn?t reproduce anymore with this fix. I also run the patch through mach5 tiers 1-7.
>> 
>> Thanks,
>> Patricio
>
> Looks good to me. Thanks for the detailed analysis.

Thanks for the reviews @dholmes-ora, @alexmenkov and @sspitsyn!

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2578734644

From cjplummer at openjdk.org  Wed Jan  8 22:58:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 22:58:27 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v9]
In-Reply-To: <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <3jlL15dxNOGhbPlWBQktux0XbjAd03fhFgW1BZJhp2A=.d48ef40c-776f-414d-a9e7-0cc3403448b8@github.com>
Message-ID: <wQtmLDXRWfrulCrhMjzrUNbcKdZH6F2BACiYkBjgyz4=.fcf052ea-4bf0-4e5e-a9cc-7857ba1efcd6@github.com>

On Tue, 7 Jan 2025 19:53:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update ciopyright year

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2538433490

From cjplummer at openjdk.org  Wed Jan  8 22:58:28 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 22:58:28 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v6]
In-Reply-To: <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <MllP26-zZy8BltkxGEEPlWwIifKpZWWrVDrG-oXb5Z0=.4656ba1b-73ec-49eb-af16-bfd81699e03c@github.com>
Message-ID: <Rj3oJ0bKxTmXW-heTcjLBbMUVL_9jOHkQ67Gk-sv_Zs=.3d7ba74a-e75e-4b81-acc5-1730de0de297@github.com>

On Tue, 7 Jan 2025 19:47:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright year

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2538432259

From cjplummer at openjdk.org  Wed Jan  8 23:02:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 23:02:35 GMT
Subject: RFR: 8347162: Update problemlist CR for
 vmTestbase/nsk/jdi/VMOutOfMemoryException
In-Reply-To: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
References: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
Message-ID: <j3EXumMATL4Ef0MKSkMOPUXGWxYdvQQ-ke-HvHeSpUY=.c907bde9-ef4b-40ca-b2f6-685599983561@github.com>

On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list entry needs to be updated.

Thank you Alex and Kevin!

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

PR Comment: https://git.openjdk.org/jdk/pull/22960#issuecomment-2578830867

From cjplummer at openjdk.org  Wed Jan  8 23:02:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Jan 2025 23:02:36 GMT
Subject: Integrated: 8347162: Update problemlist CR for
 vmTestbase/nsk/jdi/VMOutOfMemoryException
In-Reply-To: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
References: <DjNfb9ht2m1zb0sZsXpMS8kan9rFAkBUqqYHe9Uhzug=.31fb0a34-13bb-4221-a215-bf30d41be344@github.com>
Message-ID: <lc7isZlt-uIVaOQynIKaUdrT_qGYCFpUQd5EEcEP4II=.a13ec821-28a3-4152-b730-d3435a54bd09@github.com>

On Wed, 8 Jan 2025 05:23:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Since [JDK-8285417](https://bugs.openjdk.org/browse/JDK-8285417) is now closed as a dup of [JDK-8347137](https://bugs.openjdk.org/browse/JDK-8347137), its problem list entry needs to be updated.

This pull request has now been integrated.

Changeset: 0a5ef827
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a5ef827b06ca9fc6a7cbc059e4331cfd3cd2e62
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8347162: Update problemlist CR for vmTestbase/nsk/jdi/VMOutOfMemoryException

Reviewed-by: kevinw, amenkov

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

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

From dholmes at openjdk.org  Thu Jan  9 01:10:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 01:10:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v13]
In-Reply-To: <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-HnLiN9gQYv9-y-_30kif20f-OE7SuGpRmIHQ_ddIrU=.7ce6c92d-aa43-401f-a8ff-74f92d7eefef@github.com>
Message-ID: <N9Uiyr_H2bMVS0OXGCy6jcJcMp70qE0Gd1DcMo6Cs0g=.17420840-6871-4658-982b-3b319620be20@github.com>

On Wed, 8 Jan 2025 16:38:50 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Threads::is_single_threaded()

Thanks for the update but the `is_single_threaded()` check can be done more efficiently.

src/hotspot/share/runtime/threads.hpp line 159:

> 157:     }
> 158:     return count <= 1;
> 159:   }

Suggestion:

  // VM initialization is single-threaded until the first NJT (WatcherThread) is created
  // by the main thread, but that thread disappears during VM exit so we can't just
  // check for it. To reduce the overhead we check for > 1 JavaThreads first.
  static bool is_single_threaded() {
    if (number_of_threads() > 1) {
        return false;
    }
    NonJavaThread::Iterator njti;
    return njti->current() == nullptr;
  }

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2538579113
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1908054366

From sspitsyn at openjdk.org  Thu Jan  9 02:15:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 02:15:41 GMT
Subject: RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>
References: <ffdrurccN_BnKEEycCNcHeZuTidO8DljpxwrEXAgh9s=.1d3eff96-5f66-4a44-bc8d-c4ac79355b46@github.com>
 <QWoG2cS_0x3MjB_ybdYb2k3mDvjyVwjAANR_83DCnqM=.cedd4f1a-f3d7-4701-ab72-cd0b9c7757e2@github.com>
 <VPN9tX4vajCaJZ5PaWycbxzVqX4u9Sr-Ou7tsrMG7mA=.156b8712-03a8-4a57-8a04-8930bbe6bcc9@github.com>
Message-ID: <6_6xBPaAyMGanR9vGmuqW4d6Sengm_P2TTmQTb_wMbc=.0d250d88-bad6-4641-b14f-15ad7db4bdd9@github.com>

On Wed, 8 Jan 2025 17:33:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I see. Yes, we still need the handshake in JvmtiEventControllerPrivate::enter_interp_only_mode to safely walk the stack of the target to deoptimize the frames. When leaving interpreter only mode we just decrement _interp_only_mode/_saved_interp_only_mode so I don?t think we need anything else, other than making sure the change is atomic, which I think we guarantee by holding JvmtiThreadState_lock.

Agreed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22931#issuecomment-2579037121

From lmesnik at openjdk.org  Thu Jan  9 03:03:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 03:03:34 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
 <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
Message-ID: <yZmVpj8JbTwu-2xdM72uiBd0abdGcu46eiQzI2xkWZA=.720ec97a-b339-4727-85cc-4c3c4cc50394@github.com>

On Wed, 8 Jan 2025 07:45:24 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Trivial logging message change.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporated review comments

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22939#pullrequestreview-2538654753

From dholmes at openjdk.org  Thu Jan  9 03:09:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 03:09:44 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
Message-ID: <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>

On Wed, 8 Jan 2025 21:01:37 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test SystemMap with and without ZGC

Marked as reviewed by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:

> 37:  *          java.management
> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 39:  * @run testng/othervm -XX:+UsePerfData -XX:-UseZGC SystemMapTest

Technically you don't need to disable ZGC as the requires clause means it is already not the selected GC

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

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2538658134
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1908108908

From dholmes at openjdk.org  Thu Jan  9 03:32:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 03:32:38 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
 <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
Message-ID: <f0LA_ZWc7qxOOLRBQx9OZYtD6_03fo2Ee0c5QeuUOfc=.dd3410a4-774d-4d77-9706-6610266ac0c5@github.com>

On Wed, 8 Jan 2025 07:45:24 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Trivial logging message change.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporated review comments

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22939#pullrequestreview-2538675255

From sspitsyn at openjdk.org  Thu Jan  9 05:07:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 05:07:47 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
Message-ID: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>

This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.

Testing:
- Ran mach5 tiers 1-6
- There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

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

Commit messages:
 - 8346727: JvmtiVTMSTransitionDisabler deadlock

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

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

From duke at openjdk.org  Thu Jan  9 06:20:36 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Jan 2025 06:20:36 GMT
Subject: RFR: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests [v2]
In-Reply-To: <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
 <M-jPVTNta42HyfJdYL9F2cDYCSs2RGM5gLWx6a0tMV4=.80a77f4d-5c29-4943-bd14-9f30059d086b@github.com>
Message-ID: <jPdqLp5gmho5j8fRGqk1PJo9mH3JVE6hterWH6wCnmg=.6675ed3a-01e9-4b8d-9c28-d8c0702154f8@github.com>

On Wed, 8 Jan 2025 07:45:24 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Trivial logging message change.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   incorporated review comments

@rsunderbabu 
Your change (at version 28c1b8ea503f68b91c840f7095d96ab6b4ad5af3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22939#issuecomment-2579259303

From rsunderbabu at openjdk.org  Thu Jan  9 07:53:44 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 9 Jan 2025 07:53:44 GMT
Subject: Integrated: 8347083: Incomplete logging in
 nsk/jvmti/ResourceExhausted/resexhausted00* tests
In-Reply-To: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
References: <IQkhJzI08X5MDL4tf9L5xdhVfKnbs1h3SfjCfUDGGCQ=.1b44cd2d-5e56-4045-a42a-c834efd99fd3@github.com>
Message-ID: <ayRJkqaPyVGccH5HF1hvz7z4vsRX5qdca9EhCef97jI=.d3192ccd-9b8f-4b21-86d1-69ba475b403d@github.com>

On Tue, 7 Jan 2025 07:58:18 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Trivial logging message change.

This pull request has now been integrated.

Changeset: 33f9be8d
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33f9be8de730e664e335e36848732397393abd94
Stats:     6 lines in 3 files changed: 0 ins; 0 del; 6 mod

8347083: Incomplete logging in nsk/jvmti/ResourceExhausted/resexhausted00* tests

Reviewed-by: dholmes, sspitsyn, lmesnik

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

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

From sspitsyn at openjdk.org  Thu Jan  9 12:05:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 12:05:45 GMT
Subject: Integrated: 8346460: NotifyFramePop should return
 JVMTI_ERROR_DUPLICATE
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <9D3Y5T128B7aDfkUNxtoVIq_ytSx4Rwt3_O0UdD7L_0=.559dc3d2-b6dc-4af7-a9ca-97f408a68ec9@github.com>

On Tue, 17 Dec 2024 21:01:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 2801bc6b
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2801bc6bf3d5e7eff23be1a7501f7e64dda85f67
Stats:     30 lines in 3 files changed: 19 ins; 6 del; 5 mod

8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

Reviewed-by: cjplummer, amenkov

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

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

From kevinw at openjdk.org  Thu Jan  9 12:40:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Jan 2025 12:40:00 GMT
Subject: RFR: 8347345: Remove redundant test policy file from
 ModelMBeanInfoSupport directory
Message-ID: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>

A redundant policy file exists, it is unused and must have been missed during:
8338411: Implement JEP 486: Permanently Disable the Security Manager

Test in test/jdk/javax/management/modelmbean/ModelMBeanInfoSupport still passes after this change.

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

Commit messages:
 - remove old policy file

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

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

From coleenp at openjdk.org  Thu Jan  9 13:34:39 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 13:34:39 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
 <KIQisOj4krYbqY5R0a7E501pVTrA6xMEw4NPs_A4rk0=.2b15d78a-d1e8-4786-afe0-31d549dc52d5@github.com>
 <m4UIYSYEkrVlpu-36boiQG_K72oV35uV0VY2FLs6ExM=.28df9ba7-4f9e-489d-90aa-3ad312f0b006@github.com>
Message-ID: <wwAwF9ePyVJAORFl1RKLcVEnyngfLST0iQoM-e1-Bh0=.4bbff6a3-9664-4ac3-b6f8-d5ce50d1c2d6@github.com>

On Tue, 7 Jan 2025 08:32:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a relic and not the legal copyright that got updated since nobody noticed.  Until you did.  Removed.
>
> Not sure we're allowed to remove a copyright statement, even if not in the usual place.

put copyright back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1908806441

From duke at openjdk.org  Thu Jan  9 14:14:54 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 14:14:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v14]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <HbqGQieHyntMGFwXUr8KvqwPE5Z7XQthx78gxa5QL7E=.2e77d14d-e4e3-4f86-ba9a-e96e1ad80578@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/threads.hpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/379eaac8..0304668e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=12-13

  Stats: 9 lines in 1 file changed: 3 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

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

From duke at openjdk.org  Thu Jan  9 14:27:56 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 14:27:56 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  small fix to is_single_threaded and whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/0304668e..6e7bf186

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=13-14

  Stats: 6 lines in 3 files changed: 1 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

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

From pchilanomate at openjdk.org  Thu Jan  9 15:13:53 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 9 Jan 2025 15:13:53 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
Message-ID: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>

Hi all,

This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.

Thanks!

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

Commit messages:
 - Backport ea49537726db6530f0ddcc04d9938df3d6d18250

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

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

From mbaesken at openjdk.org  Thu Jan  9 15:18:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 9 Jan 2025 15:18:49 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
Message-ID: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>

When running ubsan-enabled binaries on macOS aarch64, in test
javax/management/MBeanServer/OldMBeanServerTest.java
the following division by zero is shown :
src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
UndefinedBehaviorSanitizer:DEADLYSIGNAL
UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.

We should add special handling for the case ` (total_delta == 0)` .

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

Commit messages:
 - JDK-8347267

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

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

From cjplummer at openjdk.org  Thu Jan  9 16:30:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Jan 2025 16:30:38 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

src/hotspot/share/prims/jvmtiExport.cpp line 1105:

> 1103: 
> 1104:   if (JavaThread::current()->hide_jvmti_events()) {
> 1105:     return false; // no events should be posted if thread is in VTMS alike transition

I don't think your use of "alike" is what you mean here. Did you mean "VTMS-like", or maybe something like "VTMS transition or similar state".

Also `hide_jvmti_events()` is a pretty self explanatory name already. Probably no comment is needed at the call sites, and instead you should just add a comment where `hide_jvmti_events()` is declared.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909124132

From sspitsyn at openjdk.org  Thu Jan  9 16:37:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Jan 2025 16:37:36 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <3kIPqTJxO_qVqWMYdMUMyk0NYGQdgWo6OaDrV9xUgvQ=.255ba8e1-482c-4b85-b181-38d865c5166e@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

This is a clean backport. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23007#pullrequestreview-2540409022

From duke at openjdk.org  Thu Jan  9 16:38:40 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 9 Jan 2025 16:38:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
 <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
Message-ID: <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>

On Tue, 7 Jan 2025 04:40:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> In case my comment within the existing conversations gets missed I will re-state that I don't think you need any new "is bootstrapping" logic because you can just use `Threads::number_of_threads() > 0` to tell you if you need to acquire the NMT lock. Though that assumes that the `WatcherThread` does not use NMT ... but in that case you can use `WatcherThread::watcher_thread() != nullptr` as the bootstrap condition instead.
>> 
>> I think that the `WatcherThread` does use NMT (at least upon starting), since `Thread::call_run() ` calls `register_thread_stack_with_NMT()`. However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still  be used. So checking `WatcherThread::watcher_thread() != nullptr` may not work in this case as it could be set back to nullptr too early.
>> 
>> Another solution might be to introduce something like `Threads::is_single_threaded()` which checks for  `WatcherThread`, `Threads::number_of_threads()`, and any other threads that fall outside this set. I'm not sure whether that would be better than the current approach.
>
>> However, it looks like `WatcherThread::stop()` is called early in `before_exit` -- after which point NMT can still be used. 
> 
> Yeah good catch. I just find it frustrating that we already have so many initialization-progress markers but we are looking at adding yet-another-one. Also I'm not sure this is really relevant to mutex itself per-se it is rather about whether mutexes are needed - to that end I don't find `Threads::is_single_threaded() ` a terrible suggestion.

@dholmes-ora I don't think it is enough to check whether we are single threaded.  Some GHA tests are failing with 


Internal Error (d:\a\jdk\jdk\src\hotspot\share\nmt/memTracker.hpp:68), pid=5708, tid=1620
#  assert(Threads::is_single_threaded() || NmtVirtualMemory_lock->owned_by_self()) failed: should have acquired NmtVirtualMemory_lock


Say **thread_A** is the only thread started. It does not acquire the lock (since single threaded) and enters the critical section. While **thread_A** is in the critical section, **thread_B** is started, acquires the lock (no longer single threaded), and joins **thread_A** in the critical section. The spontaneous creation of **thread_B** creates a race and also causes **thread_A** to trigger assertions checking that it is owner of the lock. 

Maybe the old approach is safer since we always acquire the lock as soon as bootstrapping makes it possible to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2580756863

From rriggs at openjdk.org  Thu Jan  9 16:43:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Jan 2025 16:43:35 GMT
Subject: RFR: 8347345: Remove redundant test policy file from
 ModelMBeanInfoSupport directory
In-Reply-To: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
References: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
Message-ID: <dP8aVGsVCx2uTCwTiCdfHC9HrUqLZn4whmXdBbEihbg=.ba07b721-fea2-4b31-ae4c-9f845bf9b67c@github.com>

On Thu, 9 Jan 2025 12:24:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A redundant policy file exists, it is unused and must have been missed during:
> 8338411: Implement JEP 486: Permanently Disable the Security Manager
> 
> Test in test/jdk/javax/management/modelmbean/ModelMBeanInfoSupport still passes after this change.

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23002#pullrequestreview-2540424234

From matsaave at openjdk.org  Thu Jan  9 19:04:51 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 19:04:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <uJRJVx-1cgnpbh7t7yfoncqGEEEbkws2BfWkUFUA7zI=.5e095d4b-0b48-4c3c-a179-e7870d6e61ad@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

>From what I've looked at so far it looks good! I noticed there are several cases where you mix format specifiers with macros. I understand that replacing other macros may not be in the scope of this change but I find it inconsistent in places where we have both. 

I listed out some of the cases below, but if you don't believe this to be necessary you can ignore me.

src/hotspot/os/bsd/os_bsd.cpp line 2527:

> 2525:              "\n\n"
> 2526:              "Do you want to debug the problem?\n\n"
> 2527:              "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zd (" INTPTR_FORMAT ")\n"

There is both `%zd` and `INTPTR_FORMAT` in this line. I think it would be more consistent to convert both to format specifiers here.

src/hotspot/os/linux/os_linux.cpp line 5276:

> 5274:                "\n\n"
> 5275:                "Do you want to debug the problem?\n\n"
> 5276:                "To debug, run 'gdb /proc/%d/exe %d'; then switch to thread %zu (" INTPTR_FORMAT ")\n"

Same as above

src/hotspot/os/windows/os_windows.cpp line 533:

> 531:   }
> 532: 
> 533:   log_info(os, thread)("Thread is alive (tid: %zu, stacksize: " SIZE_FORMAT "k).", os::current_thread_id(), thread->stack_size() / K);

Same as above, this time with `SIZE_FORMAT`

src/hotspot/os/windows/os_windows.cpp line 618:

> 616:   thread->set_osthread(osthread);
> 617: 
> 618:   log_info(os, thread)("Thread attached (tid: %zu, stack: "

This line also mixes format specifiers and macros

src/hotspot/os/windows/os_windows.cpp line 3340:

> 3338:     if (Verbose && PrintMiscellaneous) {
> 3339:       reserveTimer.stop();
> 3340:       tty->print_cr("reserve_memory of %zx bytes took " JLONG_FORMAT " ms (" JLONG_FORMAT " ticks)", bytes,

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 115:

> 113:   Klass* parent_klass = (cls._parent == nullptr ? nullptr : cls._parent->klass());
> 114: 
> 115:   _out->print(INTPTR_FORMAT "  " INTPTR_FORMAT "  " INTPTR_FORMAT "  %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

Here too

src/hotspot/share/classfile/classLoaderStats.cpp line 126:

> 124:   _out->cr();
> 125:   if (cls._hidden_classes_count > 0) {
> 126:     _out->print_cr(SPACE SPACE SPACE "                                    %6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "   + hidden classes",

And here

src/hotspot/share/classfile/classLoaderStats.cpp line 140:

> 138:   _out->print("Total = %-6zu", _total_loaders);
> 139:   _out->print(SPACE SPACE SPACE "                      ", "", "", "");
> 140:   _out->print_cr("%6zu  " SIZE_FORMAT_W(8) "  " SIZE_FORMAT_W(8) "  ",

And here

src/hotspot/share/code/vtableStubs.cpp line 82:

> 80: 
> 81: void VtableStub::print_on(outputStream* st) const {
> 82:   st->print("vtable stub (index = %d, receiver_location = %zd, code = [" INTPTR_FORMAT ", " INTPTR_FORMAT "])",

And here

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

Changes requested by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540706941
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909299619
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300550
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909300883
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301552
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909301678
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303066
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303216
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303480
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909303991

From kevinw at openjdk.org  Thu Jan  9 19:25:40 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Jan 2025 19:25:40 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
In-Reply-To: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
Message-ID: <9SzEuseztjsqQukSbuIP23kmuThvZ9vtK7BM4ntV0Hk=.8a6cfb5e-5b53-4d99-92b3-e180434da06a@github.com>

On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
> UndefinedBehaviorSanitizer:DEADLYSIGNAL
> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
> 
> We should add special handling for the case ` (total_delta == 0)` .

Hi, looks good.
It is odd that this is never known to happen (zero ticks elapsed!) before, so we might wonder what ubsan is really changing here.
But even if it only happens with ubsan, we can protect ourselves.  8-)

(as long as we aren't changing too much to suit the tool -- we don't seem to be there yet!)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23010#pullrequestreview-2540756390

From coleenp at openjdk.org  Thu Jan  9 20:39:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 9 Jan 2025 20:39:41 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <3rsYHTsq8K_5SIPzeMJQJFM6HMWNTz7OdCBgVBwUUD8=.f3b67c30-8ecb-4034-b0b7-8396c5f8b531@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

The intention is to keep INTPTR_FORMAT and some of the other format specifiers that vary by platform.  I have another issue to remove the SIZE_FORMAT ones but that's a bigger change.  So this mixture is intentional.

JLONG_FORMAT might be something we can remove too but I didn't want to do it all at once.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2581199763

From stooke at openjdk.org  Thu Jan  9 20:48:21 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 9 Jan 2025 20:48:21 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  no need to force -XX:-UseZGC

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22870/files
  - new: https://git.openjdk.org/jdk/pull/22870/files/f62bbd7c..4574a2d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=03-04

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

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

From lmesnik at openjdk.org  Thu Jan  9 21:05:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 21:05:41 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Changes requested by lmesnik (Reviewer).

src/hotspot/share/runtime/javaThread.hpp line 724:

> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
> 723: 
> 724:   bool hide_jvmti_events() const                 { return _is_in_VTMS_transition || _is_disable_suspend; }

The name
hide_jvmti_events()
looks incorrect, like we change thread state to hide jvmti event and fail/return if can't.
I prefer something like
jvmti_events_hidden()
is_jvmti_event_posting_hidden()
or 
should_hide_jvmti_events()
To make clear that we read only some state.
Also, agree with Chris that comments are needed only in the implementation of this method.

Good to know when thread can and can't post events.

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2540922332
PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909428470

From stooke at openjdk.org  Thu Jan  9 21:15:37 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 9 Jan 2025 21:15:37 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v4]
In-Reply-To: <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <sexTLjbrme-gCVabfKszi9BeME0Chqz4Cg7dOH5GNg8=.9ee2ac81-9246-44e7-bb7b-ac9894be03fc@github.com>
 <3jOPTXsCDtxgDPDlSW67E2-Sr9bOI-vIrIqoN9O8fns=.19075be5-37c0-4655-8fe4-4c633185d2bf@github.com>
Message-ID: <iEV4GdRzWm6XRgAZAYYHyrkFahIy5sPBXG7KAM0W7eQ=.29ea5706-3451-41b7-8c37-3407ae144da7@github.com>

On Thu, 9 Jan 2025 03:05:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test SystemMap with and without ZGC
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:
> 
>> 37:  *          java.management
>> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
>> 39:  * @run testng/othervm -XX:+UsePerfData -XX:-UseZGC SystemMapTest
> 
> Technically you don't need to disable ZGC as the requires clause means it is already not the selected GC

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1909438912

From cjplummer at openjdk.org  Thu Jan  9 21:24:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 9 Jan 2025 21:24:37 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
In-Reply-To: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
Message-ID: <uzgvaclUf1T1V2Szm0Lv7v3MxO3gDUENI9HDSzQXUQc=.36cd545f-7a24-4d95-8821-294de617df6e@github.com>

On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
> UndefinedBehaviorSanitizer:DEADLYSIGNAL
> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
> 
> We should add special handling for the case ` (total_delta == 0)` .

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23010#pullrequestreview-2540953217

From lmesnik at openjdk.org  Thu Jan  9 21:26:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 9 Jan 2025 21:26:42 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <YXLtAY6gddyOCfwS85hxwiK1F8Gmvhrb-uQErcnj9JE=.7e96d931-0fd9-4324-b810-02ba59ac415d@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

Test changes looks good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2540955666

From matsaave at openjdk.org  Thu Jan  9 21:52:47 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 9 Jan 2025 21:52:47 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good! I saw the discussion on `UINTPTR_FORMAT_X_0` so I left it alone.

src/hotspot/share/runtime/objectMonitor.cpp line 2500:

> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",

Is `INT64_FORMAT` different from `INTX_FORMAT`?

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2540981143
PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909469703

From kbarrett at openjdk.org  Thu Jan  9 22:00:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Jan 2025 22:00:59 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
 <2NN6jS-4TNxlwq8K0ovl2o9A3ZdCsTVJJ6NcOWDh-P8=.069b6da4-4c08-4cc6-9532-2b1f96a1793a@github.com>
Message-ID: <B6oyiuXbdW78wAwUKpFINC4wUo5MUZluKK5LkFwAbSQ=.9488e486-cc73-4f9e-ac86-08be39c525e2@github.com>

On Thu, 9 Jan 2025 21:47:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore copyright and macro.
>
> src/hotspot/share/runtime/objectMonitor.cpp line 2500:
> 
>> 2498:   // The minimal things to print for markWord printing, more can be added for debugging and logging.
>> 2499:   st->print("{contentions=0x%08x,waiters=0x%08x"
>> 2500:             ",recursions=%zd,owner=" INT64_FORMAT "}",
> 
> Is `INT64_FORMAT` different from `INTX_FORMAT`?

Currently yes.  The type underlying [u]intx varies by platform, being a 32-bit type on 32-bit platforms and a
64-bit type on 64-bit platforms.  We've been trimming the set of supported 32-bit platforms though, so maybe
someday we won't need that distinction any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1909478987

From sspitsyn at openjdk.org  Fri Jan 10 01:44:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 01:44:36 GMT
Subject: RFR: 8347345: Remove redundant test policy file from
 ModelMBeanInfoSupport directory
In-Reply-To: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
References: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
Message-ID: <3HgCLyvvUvfpIJ8XLSsWAfpQVXYSOB3jOoydBH8_0aQ=.fe18264c-22a5-4ff3-a55b-096c5ca4806f@github.com>

On Thu, 9 Jan 2025 12:24:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A redundant policy file exists, it is unused and must have been missed during:
> 8338411: Implement JEP 486: Permanently Disable the Security Manager
> 
> Test in test/jdk/javax/management/modelmbean/ModelMBeanInfoSupport still passes after this change.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23002#pullrequestreview-2541394115

From sspitsyn at openjdk.org  Fri Jan 10 01:51:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 01:51:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <2PJDQvsH4HJcxarS6uEfxPdmiqdTTwdfjF-N8eQO544=.bc362092-4acd-48e1-80e1-97c207f6b881@github.com>
Message-ID: <3kgFYEHLWogjTf_7G5ozn99ySOFbQ_pLBcAh2bEB6qE=.119f486e-a519-4ee3-a00a-15666c234461@github.com>

On Thu, 9 Jan 2025 16:28:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1105:
> 
>> 1103: 
>> 1104:   if (JavaThread::current()->hide_jvmti_events()) {
>> 1105:     return false; // no events should be posted if thread is in VTMS alike transition
> 
> I don't think your use of "alike" is what you mean here. Did you mean "VTMS-like", or maybe something like "VTMS transition or similar state".
> 
> Also `hide_jvmti_events()` is a pretty self explanatory name already. Probably no comment is needed at the call sites, and instead you should just add a comment where `hide_jvmti_events()` is declared.

Thanks. Good suggestion. Will address.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909665062

From sspitsyn at openjdk.org  Fri Jan 10 01:55:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 01:55:38 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <sSHgPYC0JMs4NMcgFz8MHFT_CvmADd41NpDFmEn6D2Q=.eabcbc36-3836-4a9f-98d3-00fdec6e4c51@github.com>
Message-ID: <20aXW3vlQ-uGIZqVPQxx41SSifFMEcMxGw0w9OuTo3I=.a2e01672-c5ad-4e5d-b8ed-ecc67f2ea1b8@github.com>

On Thu, 9 Jan 2025 21:01:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> src/hotspot/share/runtime/javaThread.hpp line 724:
> 
>> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
>> 723: 
>> 724:   bool hide_jvmti_events() const                 { return _is_in_VTMS_transition || _is_disable_suspend; }
> 
> The name
> hide_jvmti_events()
> looks incorrect, like we change thread state to hide jvmti event and fail/return if can't.
> I prefer something like
> jvmti_events_hidden()
> is_jvmti_event_posting_hidden()
> or 
> should_hide_jvmti_events()
> To make clear that we read only some state.
> Also, agree with Chris that comments are needed only in the implementation of this method.
> 
> Good to know when thread can and can't post events.

Thank you for the comment.
I like this suggestion: `should_hide_jvmti_events()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1909668564

From sspitsyn at openjdk.org  Fri Jan 10 02:13:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 02:13:09 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v2]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <XZSRdHFIqus75jIFOExEw4uFU-gLjMqG6dJIq0f7rRM=.5089b448-7075-45e4-ba64-e33b471318e7@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: renamed to should_hide_jvmti_events; removed assert and unneeded comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/2aa84d48..8cc92a90

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

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

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

From sspitsyn at openjdk.org  Fri Jan 10 02:27:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 02:27:16 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweak some assert messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/8cc92a90..46527318

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

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

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

From dholmes at openjdk.org  Fri Jan 10 07:24:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:24:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>
 <STmtFGOiMqMF6fIPive22V2eV6C_8YGpGvVbJ5J_D4E=.acc59b29-721b-4fd9-b1f6-2a740090d23f@github.com>
 <rFVSH9SrWTNh_4Ypp9BGyhJzmdF8cMAEfBwzdvvwZvk=.db236602-da52-4e78-80c5-2e89e3b7d007@github.com>
 <BlJktc_h0m47MDOqZ47OOYX1fQmJTVfqQXE3ahJGcHI=.142785d4-cfb0-4a5a-935c-dcdff26bc8b9@github.com>
 <XDj2DWCi60HZIYDmDX7Ur3jm11-PRfFHbxDR2k5p1YY=.6b2801ff-4b21-44ba-84c3-a3a660d6997c@github.com>
Message-ID: <ZHVTDvHqC88pptUappNNRoQAUEHfyShcABIlJSX-5DQ=.24762956-3b68-4ab3-aa73-01d5f2367408@github.com>

On Thu, 9 Jan 2025 16:34:08 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> Say **thread_A** is the only thread started. It does not acquire the lock (since single threaded) and enters the critical section. While **thread_A** is in the critical section, **thread_B** is started,

Hold on there - who is starting thread B? Only thread A exists and it won't create thread B from within the critical section.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2581949574

From dholmes at openjdk.org  Fri Jan 10 07:26:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Jan 2025 07:26:42 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <DZ7jtKPxUoloPYfY5PHXBq6hRZi0aE4QccvXkePIimE=.e0e21569-12ef-46e7-90b5-c0bc742f78a6@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

Looks good. Let's get this integrated! :) Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2541709646

From kevinw at openjdk.org  Fri Jan 10 08:02:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Jan 2025 08:02:50 GMT
Subject: Integrated: 8347345: Remove redundant test policy file from
 ModelMBeanInfoSupport directory
In-Reply-To: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
References: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
Message-ID: <B39FKLG7UedeuwrpFIsMT7vFbNgk_brscBLpLa4BaDU=.d1fd7c14-25f0-41c6-9583-0799c929986c@github.com>

On Thu, 9 Jan 2025 12:24:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A redundant policy file exists, it is unused and must have been missed during:
> 8338411: Implement JEP 486: Permanently Disable the Security Manager
> 
> Test in test/jdk/javax/management/modelmbean/ModelMBeanInfoSupport still passes after this change.

This pull request has now been integrated.

Changeset: 8b076172
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b076172a523ee9e845ee9d8b36e7d430206448c
Stats:     14 lines in 1 file changed: 0 ins; 14 del; 0 mod

8347345: Remove redundant test policy file from ModelMBeanInfoSupport directory

Reviewed-by: rriggs, sspitsyn

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

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

From kevinw at openjdk.org  Fri Jan 10 08:02:50 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Jan 2025 08:02:50 GMT
Subject: RFR: 8347345: Remove redundant test policy file from
 ModelMBeanInfoSupport directory
In-Reply-To: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
References: <Id70o2Tfi5OQT30avypiMn8LSSLLTLSUboFbXJLfpQU=.770f4c63-400c-4b4a-b337-1707f913a369@github.com>
Message-ID: <iNPrezP5jtblEfg78CO4y3OK3Cg5zYAhWc3340dmg9o=.7979c3cd-d5a3-4b83-80f6-c76327c01490@github.com>

On Thu, 9 Jan 2025 12:24:59 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A redundant policy file exists, it is unused and must have been missed during:
> 8338411: Implement JEP 486: Permanently Disable the Security Manager
> 
> Test in test/jdk/javax/management/modelmbean/ModelMBeanInfoSupport still passes after this change.

Thanks Roger, and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23002#issuecomment-2581997360

From mbaesken at openjdk.org  Fri Jan 10 10:04:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Jan 2025 10:04:54 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
In-Reply-To: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
Message-ID: <iiyzN81otrmdeU3NP2sEpCvWEmMsCV39rfn_DJtaNlo=.eb5bf990-2730-42ec-8845-44260fd26fcd@github.com>

On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
> UndefinedBehaviorSanitizer:DEADLYSIGNAL
> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
> 
> We should add special handling for the case ` (total_delta == 0)` .

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23010#issuecomment-2582257304

From mbaesken at openjdk.org  Fri Jan 10 10:04:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Jan 2025 10:04:54 GMT
Subject: Integrated: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime
 error: division by zero
In-Reply-To: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
Message-ID: <NBbkwD4QGQjjCGT1DDwqLWLpAIwNpTxwCpeNd9_fKQ4=.7cf16ee2-ef4d-4fbc-afa1-b08871efc9ed@github.com>

On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
> UndefinedBehaviorSanitizer:DEADLYSIGNAL
> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
> 
> We should add special handling for the case ` (total_delta == 0)` .

This pull request has now been integrated.

Changeset: 5e92a4ce
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e92a4ceafd0626e3600e44a3370ca2f5d9347c8
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error: division by zero

Reviewed-by: kevinw, cjplummer

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

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

From mbaesken at openjdk.org  Fri Jan 10 12:30:57 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 10 Jan 2025 12:30:57 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
In-Reply-To: <9SzEuseztjsqQukSbuIP23kmuThvZ9vtK7BM4ntV0Hk=.8a6cfb5e-5b53-4d99-92b3-e180434da06a@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
 <9SzEuseztjsqQukSbuIP23kmuThvZ9vtK7BM4ntV0Hk=.8a6cfb5e-5b53-4d99-92b3-e180434da06a@github.com>
Message-ID: <W_Vu2m0wyxmB4UtCaTFpupe-0IRktV02KcyMJGSLbrk=.64edd925-83d4-4ae0-bd7b-66f5d3be7ae2@github.com>

On Thu, 9 Jan 2025 19:23:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Hi, looks good. It is odd that this is never known to happen (zero ticks elapsed!) before, so we might wonder what ubsan is really changing here. But even if it only happens with ubsan, we can protect ourselves. 8-)
> 
> (as long as we aren't changing too much to suit the tool -- we don't seem to be there yet!)

Running with ubsan just _shows_ the issue, but the issue is there also without ubsan.
When running the test on macOS aarch64, product build and adding some check like this



--- a/src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c
+++ b/src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c
@@ -31,6 +31,9 @@
 
 #include "jvm.h"
 
+#include <assert.h>
+#include <stdlib.h>
+
 JNIEXPORT jdouble JNICALL
 Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0
 (JNIEnv *env, jobject dummy)
@@ -63,6 +66,11 @@ Java_com_sun_management_internal_OperatingSystemImpl_getCpuLoad0
 
     jlong used_delta  = used - last_used;
     jlong total_delta = total - last_total;
+    //assert(total_delta != 0);
+    if (total_delta == 0) {
+        printf("total_delta is 0!\n");
+        exit(1);
+    }
 


then I see the printf output ` total_delta is 0! ` also in  'normal' non-ubsan binaries when running  javax/management/MBeanServer/OldMBeanServerTest.java .
We probably just lived so far with the fact that sometimes we divide in this function by zero.

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

PR Comment: https://git.openjdk.org/jdk/pull/23010#issuecomment-2582598969

From kevinw at openjdk.org  Fri Jan 10 12:57:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Jan 2025 12:57:49 GMT
Subject: RFR: 8347267: [macOS]: UnixOperatingSystem.c:67:40: runtime error:
 division by zero
In-Reply-To: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
References: <vo_Fefa-r5EaE6aLnveDIPUGEJh0QAkeAA5inSxa_Zs=.5903f19f-7650-49af-b240-060db2c98534@github.com>
Message-ID: <qpzjWAdUoMUerckg0Y0-gCGgU6QoHoXh8nxFFExN3i4=.d3c54cc3-e2a7-4d85-bc29-fec5710349b9@github.com>

On Thu, 9 Jan 2025 15:13:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running ubsan-enabled binaries on macOS aarch64, in test
> javax/management/MBeanServer/OldMBeanServerTest.java
> the following division by zero is shown :
> src/jdk.management/macosx/native/libmanagement_ext/UnixOperatingSystem.c:67:40: runtime error: division by zero
> UndefinedBehaviorSanitizer:DEADLYSIGNAL
> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
> 
> We should add special handling for the case ` (total_delta == 0)` .

Thanks - it is good to have this check.
It had to be at least interesting, that this code is old, it's in jdk9 or earlier, and we don't seem to have seen this kind of crash before.  I was thinking maybe just the timing had changed in that build, but if you can hit it in a regular build then it's not ubsan, maybe you are just lucky!

The existing Linux versions that take zero ticks difference to imply zero load, make sense to me. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/23010#issuecomment-2582647679

From coleenp at openjdk.org  Fri Jan 10 12:57:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 10 Jan 2025 12:57:51 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v2]
In-Reply-To: <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <A_x20JhsJb5imUh5NBeOKcqnYRxkotdaKX3CuHdOsEk=.67354402-e288-469c-b769-f916709348c3@github.com>
 <zGwlMF7xRujjzzjXCzhUR1jKekTIH_0kEEaRZGbcjPk=.83bee42b-5ae2-4a2a-abed-1284767fd68a@github.com>
Message-ID: <r_LpVoELuStl0SNSzjpRLO2q9UxluZ0pbSb1zt6V1Z4=.1705d0d1-f485-46e8-a7b9-4eb75619a643@github.com>

On Sat, 4 Jan 2025 09:41:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix %Ix to %zx.
>
> src/hotspot/share/oops/klass.cpp line 1308:
> 
>> 1306:   if (secondary_supers() != nullptr) {
>> 1307:     st->print("  - "); st->print("%d elements;", _secondary_supers->length());
>> 1308:     st->print_cr(" bitmap: " LP64_ONLY("0x%016zu") NOT_LP64("0x%08zu"), _secondary_supers_bitmap);
> 
> Same as in instanceKlass - maybe this shouldn't be changed at all.

I restored this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22916#discussion_r1910340969

From duke at openjdk.org  Fri Jan 10 13:29:48 2025
From: duke at openjdk.org (duke)
Date: Fri, 10 Jan 2025 13:29:48 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id" [v5]
In-Reply-To: <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
 <RemO8EHbn1cAOmPGnGJu1v8UDNtvUayHrP8EibZZkCg=.100bf233-1ff4-454d-abc5-63f83cf6b6f6@github.com>
Message-ID: <3JLn86WueKwmXw1dAa55zg8daMP_hN6rtOOuiXCdGiQ=.c0fcf30a-4d06-43b7-ae01-158d7d0e2e51@github.com>

On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need to force -XX:-UseZGC

@stooke 
Your change (at version 4574a2d00f365f4c77af3a719a23c237ee102fe8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22870#issuecomment-2582711707

From sgehwolf at openjdk.org  Fri Jan 10 14:57:09 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Jan 2025 14:57:09 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v15]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Fix missing imports
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Add exclusive access dirs directive for systemd tests
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb

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

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=14
  Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

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

From kevinw at openjdk.org  Fri Jan 10 15:08:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Jan 2025 15:08:11 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal
Message-ID: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>

DescriptorSupport has a constructor and a method providing creation from, and export to, XML.

This is unused in the JDK and has no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

Getting PR out for visibility.  CSR will be added.

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

Commit messages:
 - (c)
 - typo
 - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
 - Also XMLParseException
 - RMMB comment update
 - Deprecate XML interchange in DescriptorSupport

Changes: https://git.openjdk.org/jdk/pull/23038/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347433
  Stats: 20 lines in 3 files changed: 13 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23038/head:pull/23038

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

From pchilanomate at openjdk.org  Fri Jan 10 15:29:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Jan 2025 15:29:47 GMT
Subject: [jdk24] RFR: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <hLidDqyoujg5apREhJ-M3cnyoA1vZ9-EiJgOqNJbh7E=.77f794f2-3345-4f01-b2d9-73307b12c8a5@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/23007#issuecomment-2582958425

From pchilanomate at openjdk.org  Fri Jan 10 15:29:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Jan 2025 15:29:47 GMT
Subject: [jdk24] Integrated: 8310340: assert(_thread->is_interp_only_mode() ||
 stub_caller) failed: expected a stub-caller
In-Reply-To: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
References: <TLgir1u0AdBNp4MWzjrH4occEThvbCaFoqZuK9be3yM=.5e34c088-62fd-48cd-b315-b8052db5de9d@github.com>
Message-ID: <lz6dxxgrPcsgMdzQ3G5mWx0JRvfl7KiYidnym4VYakI=.c98aeada-3e4d-4000-aa36-f9d5fdbbfa0d@github.com>

On Thu, 9 Jan 2025 14:18:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea495377](https://github.com/openjdk/jdk/commit/ea49537726db6530f0ddcc04d9938df3d6d18250) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Patricio Chilano Mateo on 8 Jan 2025 and was reviewed by David Holmes, Alex Menkov and Serguei Spitsyn.
> 
> Thanks!

This pull request has now been integrated.

Changeset: f0a89c5d
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f0a89c5d8e00609db6a25b69dab04a1c955b23c5
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8310340: assert(_thread->is_interp_only_mode() || stub_caller) failed: expected a stub-caller

Reviewed-by: sspitsyn
Backport-of: ea49537726db6530f0ddcc04d9938df3d6d18250

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

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

From lmesnik at openjdk.org  Fri Jan 10 16:29:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 10 Jan 2025 16:29:46 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <VnLtpEw7owhDPfS9IUJi6xVFRPSe1ZdiKsusTejjst0=.1fd7eced-88b9-4fec-922f-fcbdea61deb2@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2542895372

From ihse at openjdk.org  Fri Jan 10 17:54:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 10 Jan 2025 17:54:45 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <C2ARdULJrd7y57LEH5mWoL_aZ6VdPGA4x-xb-dMw1_A=.aac57e04-c68b-4b74-bea1-80915b301182@github.com>

On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

Can I get any reviewers for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/22789#issuecomment-2583361481

From cjplummer at openjdk.org  Fri Jan 10 18:13:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Jan 2025 18:13:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

src/hotspot/share/runtime/javaThread.hpp line 724:

> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
> 723: 
> 724:   // Temporarily skip posting JVMTI events for safety reasons when executions is in ia critical section:

Suggestion:

  // Temporarily skip posting JVMTI events for safety reasons when execution is in a critical section:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1910796441

From duke at openjdk.org  Fri Jan 10 19:18:44 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 10 Jan 2025 19:18:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
Message-ID: <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>

On Thu, 9 Jan 2025 14:27:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix to is_single_threaded and whitespace

Yes, good point. 
However, I think there is actually another problem: Threads may use NMT before `Threads::add` or `NonJavaThread::add_to_the_list()` is called. This means `is_single_threaded()` could erroneously return `true`, and the lock/asserts won't be used when they should be.

For JavaThreads:
In `attach_current_thread`, `create_stack_guard_pages()` and `register_thread_stack_with_NMT()` are called before `Threads::add`.

For NonJavaThreads:
In `Thread::call_run()`, `register_thread_stack_with_NMT()` is called before `NonJavaThread::pre_run()` which later calls `NonJavaThread::add_to_the_list()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2583681726

From sspitsyn at openjdk.org  Fri Jan 10 23:51:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Jan 2025 23:51:48 GMT
Subject: Integrated: 8346143: add ClearAllFramePops function to speedup
 debugger single stepping in some cases
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <rGoUVLP3JSCG9njmYMtxkFpDNCLsn6tmB-Cc4gKP8nI=.281469bf-d156-42f6-8377-b624a6b596e0@github.com>

On Fri, 13 Dec 2024 20:50:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

This pull request has now been integrated.

Changeset: 761774a1
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/761774a120f4aa326da3c55a000dacc5549762e9
Stats:     398 lines in 11 files changed: 362 ins; 12 del; 24 mod

8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

Reviewed-by: cjplummer, amenkov

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

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

From sspitsyn at openjdk.org  Sat Jan 11 00:06:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 00:06:35 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <P2SREKRRblPmcDo3OPK4A_6zsKWQyBg0UoNzcO2IxOk=.76db059c-7ce3-49c7-bce3-371054a58095@github.com>

On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

This looks good but needs copyright year updates.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22789#pullrequestreview-2544349432

From sspitsyn at openjdk.org  Sat Jan 11 06:01:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:33 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: fixed a typo in new comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22997/files
  - new: https://git.openjdk.org/jdk/pull/22997/files/46527318..a85b5985

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22997&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22997&range=02-03

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

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

From sspitsyn at openjdk.org  Sat Jan 11 06:01:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:35 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
Message-ID: <ZwUc37p3sSJ83kI_SKymNgXiyo38X_QIBfYt7DaRptQ=.c294358c-1f03-4ff5-ad28-71c3bd83ea45@github.com>

On Fri, 10 Jan 2025 02:27:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak some assert messages

Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22997#issuecomment-2585098218

From sspitsyn at openjdk.org  Sat Jan 11 06:01:36 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 06:01:36 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v3]
In-Reply-To: <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <8UsWOyb63_bJzULYl-q5Cn4cXGoc2nykIoL3twWhQJg=.4ccfa736-a36a-4d84-9549-8b291511cba9@github.com>
 <9EOC6fmFv6C-XLDA2Ac1q9G5TNxLlggrJiyzpf5dA3w=.cf03f3d1-ba15-4ab4-9668-62baa7aed90b@github.com>
Message-ID: <iFOnUG99PvEljDbvsWsmdv0S97-fqZITbExKZp7fiGY=.ddf787de-1a60-45dc-8794-30cc024085ba@github.com>

On Fri, 10 Jan 2025 18:10:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak some assert messages
>
> src/hotspot/share/runtime/javaThread.hpp line 724:
> 
>> 722:   void set_VTMS_transition_mark(bool val)        { Atomic::store(&_VTMS_transition_mark, val); }
>> 723: 
>> 724:   // Temporarily skip posting JVMTI events for safety reasons when executions is in ia critical section:
> 
> Suggestion:
> 
>   // Temporarily skip posting JVMTI events for safety reasons when execution is in a critical section:

Thank you. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22997#discussion_r1911903539

From cjplummer at openjdk.org  Sat Jan 11 06:42:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 11 Jan 2025 06:42:35 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
Message-ID: <zPkvJuM-pVt4qFesN8ZH5zi3ltspmu6T7SxPsxrLk30=.ecdfe208-60e1-4044-a6cd-a7388eef80d7@github.com>

On Sat, 11 Jan 2025 06:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed a typo in new comment

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22997#pullrequestreview-2544580274

From sspitsyn at openjdk.org  Sat Jan 11 07:10:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 07:10:45 GMT
Subject: RFR: 8346727: JvmtiVTMSTransitionDisabler deadlock [v4]
In-Reply-To: <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
 <rc1rKme4XUfMVWNWStl12rSpD3WoAIExSVyNXAcW8Wc=.9f8cdbef-6210-4175-be45-5bff62854a19@github.com>
Message-ID: <D81TPa_DzynhDl_LoM7j97KjO0_aa8Zoc3jiwuNpe0s=.66d2a74c-c1f8-4b7a-a8ba-4be23714fc75@github.com>

On Sat, 11 Jan 2025 06:01:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
>> 
>> Testing:
>> - Ran mach5 tiers 1-6
>> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: fixed a typo in new comment

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/22997#issuecomment-2585126654

From sspitsyn at openjdk.org  Sat Jan 11 07:10:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 11 Jan 2025 07:10:46 GMT
Subject: Integrated: 8346727: JvmtiVTMSTransitionDisabler deadlock
In-Reply-To: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
References: <dLPYHZ11YpA4vFUB-SLoxHFIGCJvI5uUML_Kg1KaJdo=.b18e39ee-c307-4813-afdb-a49fae4e6bce@github.com>
Message-ID: <hWT6ikGnGXJNKnHorByizPC7WXu-VxII1FSZBBhvxkg=.7e0cbb96-95c4-4b8f-bd07-387331df4a01@github.com>

On Thu, 9 Jan 2025 05:03:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This is a fix of one more deadlock issue related to `interruptLock` critical sections. When the `interruptLock` is hold by the target virtual thread it is unsafe to suspend or post JVMTI events. This update is to ignore the JVMTI events when the `interruptLock` is hold. It is additionally to the cases when the target JavaThread is in a `VTMS` transition. It is based on the existing mechanism disallowing JVMTI suspends while the `interruptLock` is hold. In order to support this the target JavaThread has the `_is_disable_suspend` bit.
> 
> Testing:
> - Ran mach5 tiers 1-6
> - There is no regression test for this issue as it is not hard to construct one. Originally, the issue was reported by JGroups which is using the `Async` profiler.

This pull request has now been integrated.

Changeset: 31452788
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3145278847428ad3a855a3e2c605b77f74ebe113
Stats:     57 lines in 2 files changed: 5 ins; 2 del; 50 mod

8346727: JvmtiVTMSTransitionDisabler deadlock

Reviewed-by: cjplummer, lmesnik

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

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

From kbarrett at openjdk.org  Sat Jan 11 14:11:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Jan 2025 14:11:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <0T6dqXyqum7hEpCvg97-WsP_zVfOO9JkBCnze1f3sxE=.9b5c6ba1-9f58-4e74-bee8-5478809216cc@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2544851802

From jwaters at openjdk.org  Sun Jan 12 09:31:48 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 12 Jan 2025 09:31:48 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <ErrO8UcHDqJ28tAbB_5wd9fXzI6gpyUKCQLCs7cooh0=.30ba7860-b667-4d89-b3c9-ef03762d5fe7@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2585658045

From stooke at openjdk.org  Sun Jan 12 21:42:41 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Sun, 12 Jan 2025 21:42:41 GMT
Subject: Integrated: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id"
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <l26xG9ppLBxmrNSlDevMUv7N1j3NxHI2cp6gXTo54HE=.4c2fd2a8-e786-448c-a3e4-3d2a19b45d02@github.com>

On Mon, 23 Dec 2024 18:43:07 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

This pull request has now been integrated.

Changeset: f04a6422
Author:    Simon Tooke <stooke at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f04a6422469709d22bd92bf5d00655f741956efd
Stats:     16 lines in 2 files changed: 13 ins; 0 del; 3 mod

8346717: serviceability/dcmd/vm/SystemDumpMapTest.java failing on Windows with "Stack base not yet set for thread id"

Reviewed-by: lmesnik, dholmes

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

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

From dholmes at openjdk.org  Mon Jan 13 02:58:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 02:58:41 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
Message-ID: <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>

On Fri, 10 Jan 2025 19:15:29 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> For JavaThreads:
In attach_current_thread, create_stack_guard_pages() and register_thread_stack_with_NMT() are called before Threads::add.

You can't attach to a VM until a certain point deep into initialization has been reached.

> For NonJavaThreads:
In Thread::call_run(), register_thread_stack_with_NMT() is called before NonJavaThread::pre_run() which later calls NonJavaThread::add_to_the_list().

Yes it is a problem that the created thread adds itself to the list.

So a simple solution would be to just use `Thread::number_of_threads() > 0` as the guard. That means we will skip the lock whilst it is unsafe to try and use it, then start using it once the main thread has "attached" even though it is not technically needed until there is another thread created.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2586086059

From dholmes at openjdk.org  Mon Jan 13 03:10:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 03:10:38 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <0i2P--KVfpUtf9XDfdt8Wb7NkXlX4PA4oCYuj_lPR6c=.bc82871e-1810-4ae3-9ac0-1b2517a75424@github.com>

On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

Exactly when will `WSACleanup` get called via the atexit handler versus when it gets called today? I suspect it is sooner than when `DllMain` with  `DLL_PROCESS_DETACH` would be called. In which case do we now risk tearing down socket support whilst it may still be in use?

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

PR Review: https://git.openjdk.org/jdk/pull/22789#pullrequestreview-2545635934

From dholmes at openjdk.org  Mon Jan 13 05:05:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 05:05:49 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <z6KX0QT-sCHVU0qxP9FANjzknbPOXPi8X-wNzGqDZO4=.ebcb8ad4-f9e2-4d46-abff-e7aec4f3c8da@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

Sorry for a "dumb" question but `%z` is for size_t arguments, so why are we using it to replace INTX/UINTX_FORMAT ??? I get that size_t and intx happen to be the same size but still ... if I see  `%z` I expect to see a size_t argument passed in.

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2545711471

From stuefe at openjdk.org  Mon Jan 13 07:42:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 13 Jan 2025 07:42:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
Message-ID: <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>

On Thu, 9 Jan 2025 14:27:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small fix to is_single_threaded and whitespace

Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.

We get deadlock prevention but also get brittle at initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2586403297

From ihse at openjdk.org  Mon Jan 13 12:29:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Jan 2025 12:29:36 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <gU6ZgOTQasRZ8vbSzy_1ijjtSngaesczBJGar1CbVWM=.c88d86d8-1a9f-444c-b74b-7f45f3788b53@github.com>

On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

My understanding is that it is later. But I am also not sure if this is well-specified or just an implementation detail. I'd say our code is broken if we rely on anything working between ` DLL_PROCESS_DETACH` and `atexit` handlers are called. I seriously doubt that is the case.

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

PR Comment: https://git.openjdk.org/jdk/pull/22789#issuecomment-2586973062

From coleenp at openjdk.org  Mon Jan 13 13:29:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 13:29:45 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v5]
In-Reply-To: <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <h4GPekl7HldFB2kby-h69Few4vhoBy23KCnaFsAt6xU=.8b121c4f-32c4-47e5-9289-934e6bab7e89@github.com>
Message-ID: <HDHz6YY_yMee4MQtLcxHM-k_h7wyG2x3Y0aDtPSizjA=.f328bf5f-b5d7-444a-b7d5-e8dacdad2fcb@github.com>

On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore copyright and macro.

They are interchangeable and some places  used UINTX_FORMAT when they should have used SIZE_FORMAT.
Better to have just one and just use %zu, which looks better in the format specifiers. I'm going to do SIZE_FORMAT next but still negotiating how to handle review tedium.

The error message can be confusing though because the error message for %z refers to size_t.   But some of our use of intx should probably be size_t.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2587101349

From ihse at openjdk.org  Mon Jan 13 13:31:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Jan 2025 13:31:44 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
 [v2]
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <7LYfzKu0grxnQfeAaZhNlpyHkMTZ9Rk7PO1ZtAwemWk=.e848ae9f-4064-4641-8b4b-26227d237ade@github.com>

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

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

  Update copyright years to 2025

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22789/files
  - new: https://git.openjdk.org/jdk/pull/22789/files/ea53ff03..7edefdd9

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

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

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

From coleenp at openjdk.org  Mon Jan 13 15:49:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 15:49:15 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add Oracle copyright to shenandoah files for this change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22916/files
  - new: https://git.openjdk.org/jdk/pull/22916/files/ae9d9f6f..763c3908

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

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

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

From duke at openjdk.org  Mon Jan 13 16:39:46 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 16:39:46 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <zE0jVVKb2TKAXnNtW3OLYacDLqz2SUYcd5LmhW7xEZw=.c9ef823d-cbac-417d-b89a-7774a73f7c9a@github.com>
Message-ID: <rClbYbW97ffmPAQRTuwm28NuPgKIAGpuMZYfl_eEM-o=.d8f30ad5-e145-45cb-a896-76657c343a59@github.com>

On Mon, 13 Jan 2025 07:40:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   small fix to is_single_threaded and whitespace
>
> Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.
> 
> We get deadlock prevention but also get brittle at initialization.

@tstuefe 
> Do we still think using hotspot Mutexes is a good goal? As opposed to Roberts's original attempt of using a non-asserting platform mutex? What do people think? I myself am not so sure anymore.
We get deadlock prevention but also get brittle at initialization.

Being brittle at initialization is unfortunate, and there is also the point @kimbarrett mentions about this [only working with VM threads](https://github.com/openjdk/jdk/pull/22745#discussion_r1894657610). I am not exactly sure what the best choice is here, but I do think deadlock detection is very nice since the NMT locking is quite broad in scope. I believe, in most cases, we lock around both the NMT accounting and the actual memory operation.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2587616074

From kbarrett at openjdk.org  Mon Jan 13 16:54:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 13 Jan 2025 16:54:53 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <DCTXOr09_AWxG0ET1DP5q5n8B6TN29PM4_Cj6DGHB6o=.b4cedcdd-90c7-4fff-a100-aa49761c5e41@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Still good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547230951

From duke at openjdk.org  Mon Jan 13 17:49:27 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 17:49:27 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v16]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  fix concurrency bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/6e7bf186..3fbacd6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=14-15

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

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

From kevinw at openjdk.org  Mon Jan 13 17:55:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Jan 2025 17:55:46 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in RMIConnectionImpl
Message-ID: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>

This is a post-SecurityManager-removal cleanup, following-on from:

8344394: Remove SecurityManager and related calls from java.management.rmi 


Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
Remove wrapping of Exceptions in PrivilegedActionException.

The methods that invoke an operations handle the expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.

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

Commit messages:
 - unnecessary catches
 - (c)
 - 8345079: Simplify/cleanup Exception handling in RMIConnectionImpl

Changes: https://git.openjdk.org/jdk/pull/23072/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345079
  Stats: 240 lines in 1 file changed: 99 ins; 60 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/23072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23072/head:pull/23072

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

From duke at openjdk.org  Mon Jan 13 20:56:47 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 20:56:47 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
Message-ID: <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>

On Mon, 13 Jan 2025 02:56:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So a simple solution would be to just use Thread::number_of_threads() > 0 as the guard. That means we will skip the lock whilst it is unsafe to try and use it, then start using it once the main thread has "attached" even though it is not technically needed until there is another thread created.

Hi @dholmes-ora, I think it would still be problem that NonJavaThreads (such as `WatcherThread` and `AsyncLogWriter`) may use NMT before main_thread is "attached" and detectable with `Thread::number_of_threads()`. 

Both JavaThreads and NonJavaThreads can use NMT before being detectable by `Thread::number_of_threads()` or `NonJavaThread::end()`. Threads also use NMT after `Threads::remove` or `NonJavaThread::remove_from_the_list()` is called.  So it seems that even checking both `Thread::number_of_threads()` and `NonJavaThread::end()` doesn't reliably tell us whether the lock needs to be taken.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588176443

From dholmes at openjdk.org  Mon Jan 13 21:07:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:07:44 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <9iKSUKvDXxUoqoAxOYVEqzUGmf2PQwDLy_MfbFABs88=.30a14b62-a21e-4a6e-bf32-31454689a33f@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22916#pullrequestreview-2547892700

From dholmes at openjdk.org  Mon Jan 13 21:14:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:14:37 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
 [v2]
In-Reply-To: <7LYfzKu0grxnQfeAaZhNlpyHkMTZ9Rk7PO1ZtAwemWk=.e848ae9f-4064-4641-8b4b-26227d237ade@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
 <7LYfzKu0grxnQfeAaZhNlpyHkMTZ9Rk7PO1ZtAwemWk=.e848ae9f-4064-4641-8b4b-26227d237ade@github.com>
Message-ID: <YmqQA01G-KQO0Nx80zFVeGXmdjB4vavlGocdULUZtSM=.b0ca9827-4b3a-494d-b703-7f39b3582530@github.com>

On Mon, 13 Jan 2025 13:31:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
>> 
>> 1) This is not called for statically linked libraries, and
>> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
>> 
>> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
>> 
>> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years to 2025

I will click approve but I think we need to keep a careful eye out for odd network related failures during shutdown.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22789#pullrequestreview-2547910996

From dholmes at openjdk.org  Mon Jan 13 21:24:44 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 21:24:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
 <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
Message-ID: <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>

On Mon, 13 Jan 2025 20:53:32 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> I think it would still be problem that NonJavaThreads (such as WatcherThread and AsyncLogWriter) may use NMT before main_thread is "attached" 

Sorry yes of course that is how we started on this current round - the WatcherThread is created before the main thread is "attached". <sigh>

I need to rewind a few steps and see exactly what it is we need to be initialized before this lock can be used ...

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588242206

From ihse at openjdk.org  Mon Jan 13 21:25:44 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 13 Jan 2025 21:25:44 GMT
Subject: Integrated: 8346383: Cannot use DllMain in libdt_socket for static
 builds
In-Reply-To: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
References: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@github.com>
Message-ID: <9DgyBjN37BdgcOfIfJVELSOuMEIo1fMvBOojM1mQUew=.368475d9-59e2-4ed5-9f03-eaa3b37d7fd8@github.com>

On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> To be able to properly support static builds on Windows in [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use `DllMain`, for two reasons:
> 
> 1) This is not called for statically linked libraries, and
> 2) There are multiple `DllMain` definitions throughout the JDK native libraries, causing name collisions.
> 
> While it could have been possible to keep the `DllMain` function for non-static builds and just use an alternative solution for static builds, I think it is preferable to have a single solution that works as well for both static and dynamic builds.
> 
> On top of this, the existing solution was contrary to [Microsoft recommendations](https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-wsacleanup), which state: "The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the DllMain function in a application DLL. This can potentially cause deadlocks. "

This pull request has now been integrated.

Changeset: d3a7ac22
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3a7ac22c9b0a131d2e45bf2d7c5ce8b9e3e3bdd
Stats:     42 lines in 4 files changed: 19 ins; 13 del; 10 mod

8346383: Cannot use DllMain in libdt_socket for static builds

Reviewed-by: dholmes, sspitsyn

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

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

From kevinw at openjdk.org  Mon Jan 13 21:30:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Jan 2025 21:30:45 GMT
Subject: RFR: 8342996: Enhance Attach API to support arbitrary length
 arguments - OSX
In-Reply-To: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
References: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
Message-ID: <r-DQJ8bLpFbUGoiKIEAl9FjMjPIZn6OPqzE-S06AZUQ=.6c6d6c32-6c1b-4d21-bded-593be8855b1a@github.com>

On Fri, 3 Jan 2025 01:57:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates client side of OSX implementation to support Attach API v2.
> Server side is shared with Linux and was updated by #22223.
> The changes are identical to client-side changes for Linux from #22223.
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc

Looks good to me.  Will be goo to have them all done. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22907#pullrequestreview-2547950990

From coleenp at openjdk.org  Mon Jan 13 22:06:49 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:49 GMT
Subject: Integrated: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros
In-Reply-To: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
Message-ID: <VmPON0_Nu8ZAN4fnn9hVsqXUld7G0_30HXd3mMO2Qc0=.47ab2394-eab0-4aea-9cd4-a68efb95e5c2@github.com>

On Fri, 3 Jan 2025 14:32:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
> 
> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.

This pull request has now been integrated.

Changeset: 379d05bc
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/379d05bcc130446086786ecf6ca5a6b8e977386c
Stats:     344 lines in 83 files changed: 6 ins; 19 del; 319 mod

8346990: Remove INTX_FORMAT and UINTX_FORMAT macros

Reviewed-by: kbarrett, dholmes, matsaave

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

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

From coleenp at openjdk.org  Mon Jan 13 22:06:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 13 Jan 2025 22:06:48 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <etmswFtqnPXNzddiLOqeIxwK6Qk-Z0oi6ldpjTB1icQ=.bc830122-dddb-4c0c-964a-f0d2a4116535@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

Thank you Matias, Kim and David.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588312123

From duke at openjdk.org  Mon Jan 13 22:18:44 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 13 Jan 2025 22:18:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v15]
In-Reply-To: <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <4iYHJVAcZAChdOzNWWrvF36u1E5Tjjt2Y69fUxV0zvg=.d1927bf1-395b-4bea-af8f-a3d65d062c05@github.com>
 <Y_6kSTsvC5dSlH-vvsLhxncrYH8N1IyJxGqQRtozcAM=.e58c13b4-5ca6-4e4e-af18-ac96a47fcc1a@github.com>
 <7BQzl8bBJgpG5VHq0C_7SUeKQ9zDJqaHxcUXmEqWeg4=.9b386c4f-c4f5-458d-8ffc-1c0a22f888d5@github.com>
 <bRN_qDUZQ_a4iGZaze7HWIPY4IZ94AjA4Hj-6XZyGSI=.35ae15f4-3ffb-46ef-b608-ff3cf4fcc846@github.com>
 <SqAh3fJ9CvLSSH_HnhENLsRCeStQsQ2Lzmvr8Meqr7I=.1885ea66-cf29-498e-9594-24afd0c5beaa@github.com>
Message-ID: <Gtc3-Qb3m0UWUg-q4d7kHoGdXo_2Fnj6ij22dqnwuxw=.ec1625c2-63c4-4207-a877-f03b71ba032f@github.com>

On Mon, 13 Jan 2025 21:21:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>I need to rewind a few steps and see exactly what it is we need to be initialized before this lock can be used

Before `NmtVirtualMemoryLocker` can be used, Hotspot mutexes must be initialized (`vm_init_globals()`) and `main_thread->initialize_thread_current()` must be called.  This happens relatively early in `create_vm`.

Hmmm I'm not sure anymore if introducing `is_single_threaded()` is the best approach.  [The original intention](https://github.com/openjdk/jdk/pull/22745#issuecomment-2574379871) was to avoid introducing yet another initialization-progress marker by pivoting from the old approach of setting `Mutex::is_bootstrapping_done()` as soon as it is safe to use `NmtVirtualMemoryLocker` . The downside I've discovered is that there doesn't seem to be a good way to reliably implement `is_single_threaded()` such that it's safe to guard `NmtVirtualMemoryLocker` usage.  And the various workarounds that seem to be necessary make me feel like this approach is more brittle than the original, while at the same time end up tailoring `is_single_threaded()` specifically to this NMT use case - which goes against our original goal.  What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588335419

From dholmes at openjdk.org  Tue Jan 14 01:18:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 01:18:43 GMT
Subject: RFR: 8346990: Remove INTX_FORMAT and UINTX_FORMAT macros [v6]
In-Reply-To: <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
References: <3DB-2pH7wwVWDuJfkD1XoQwGKJOYxJKhuDQ0UeuxBC4=.03b5f432-6051-49d9-8ea9-34a9ea769ad1@github.com>
 <QOUmg6TtGuTVjCpeEp5y5pBKRZNBF7BkqGeWqEm9VjQ=.ff3e7903-d94e-4d76-9430-81b8c25c1ffc@github.com>
Message-ID: <yM_EWXlhNXi16bxEFqX_NIw0ja9wU2iI5g7ZT0gljA8=.45b47ef6-43aa-400b-a68a-84608478880a@github.com>

On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> There are a lot of format modifiers that are noisy and unnecessary in the code.  This change removes the INTX variants.  It's not that disruptive even for backporting because %z modifier has been available for a long time so should backport fine.  This was mostly done with a sed script plus some hand fixups.
>> 
>> Testing mach5 and other platform cross compilations in progress.  Opening this for GHA testing.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add Oracle copyright to shenandoah files for this change.

We have belatedly discovered that `0x%zx` and `%#zx` behave differently in their handling of zero. The former prints `0x0` while the latter just prints `0`. This has broken the compiler replay tests as the parsing of 0 no longer works.

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

PR Comment: https://git.openjdk.org/jdk/pull/22916#issuecomment-2588550581

From amenkov at openjdk.org  Tue Jan 14 01:29:43 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 14 Jan 2025 01:29:43 GMT
Subject: RFR: 8342996: Enhance Attach API to support arbitrary length
 arguments - OSX
In-Reply-To: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
References: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
Message-ID: <NQqQKutq4po_0Ny15IJ4gubanKjaOeEurzMTqaSNrZ0=.37592779-dcb4-417a-a7c4-f831c91b146a@github.com>

On Fri, 3 Jan 2025 01:57:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates client side of OSX implementation to support Attach API v2.
> Server side is shared with Linux and was updated by #22223.
> The changes are identical to client-side changes for Linux from #22223.
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc

Thank you for the review Serguei and Kevin

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

PR Comment: https://git.openjdk.org/jdk/pull/22907#issuecomment-2588561644

From amenkov at openjdk.org  Tue Jan 14 01:29:43 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 14 Jan 2025 01:29:43 GMT
Subject: Integrated: 8342996: Enhance Attach API to support arbitrary length
 arguments - OSX
In-Reply-To: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
References: <bjThRz6fAv0lp7j_iI4U0s3FNh57hy3ZdyU3yDpngpM=.3d58e280-2095-49f0-b0a4-9398f75c7ede@github.com>
Message-ID: <tBIYwdFIYPQ28r1YfFiypqwnZJSn8wyFJ80lrEsEopI=.6aa5824a-0c09-422c-a5af-c7900c941d79@github.com>

On Fri, 3 Jan 2025 01:57:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates client side of OSX implementation to support Attach API v2.
> Server side is shared with Linux and was updated by #22223.
> The changes are identical to client-side changes for Linux from #22223.
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc

This pull request has now been integrated.

Changeset: 0ae5c6b3
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ae5c6b38b93125644416e973915608d100f0b16
Stats:     52 lines in 1 file changed: 15 ins; 26 del; 11 mod

8342996: Enhance Attach API to support arbitrary length arguments - OSX

Reviewed-by: sspitsyn, kevinw

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

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

From syan at openjdk.org  Tue Jan 14 02:46:54 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 14 Jan 2025 02:46:54 GMT
Subject: Withdrawn: 8339701: Test TestPinCaseWithCFLH.java fails with -Xcomp
In-Reply-To: <dkmvqjBNw4nyY8MvqMfxke4R6bqfLkJ1ykLnTjPLdWM=.b346fba0-6a15-4726-9e6d-485ca4969927@github.com>
References: <dkmvqjBNw4nyY8MvqMfxke4R6bqfLkJ1ykLnTjPLdWM=.b346fba0-6a15-4726-9e6d-485ca4969927@github.com>
Message-ID: <KEh0M-fqGPGCavtHqOA4e0PajF_SOv6Htwh53Jmayl8=.9a21379d-7098-4937-889c-01c487b937e9@github.com>

On Sun, 8 Sep 2024 15:30:21 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
>   The newly added testcase `serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java` fails with `-Xcomp` jvm option. The jvm option `-Xcomp` will make `BackgroundCompilation` false. In this test, disable `BackgroundCompilation` will make `instrumentation` in `premain` throw `java.util.MissingResourceException` in some test  environments. If I add `Thread.sleep(1000)` or `System.gc();` before `instrumentation.addTransformer`, this test also passed with `-Xcomp`.
>    So, I think it's necessary add `-XX:+BackgroundCompilation` option for this test to make this test more robustness, to make this test run passed with `-Xcomp` option.
>   Test-fix only, no risk.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Tue Jan 14 03:33:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 03:33:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v16]
In-Reply-To: <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <aeAn4lTnQ5cJeSkbU6olE07bYeZzSfILzCfg96k3P_U=.6523a762-c243-4ddc-85f8-9688a2580994@github.com>
Message-ID: <fhSwicib-dt0Zb3lQkUGr2XvnevaR51wRaFEynzowwE=.084d00d1-03c1-4a38-bda3-a98368458fe5@github.com>

On Mon, 13 Jan 2025 17:49:27 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix concurrency bug

I agree `is_single_threaded` has not worked out - unfortunately.

But I'd prefer to see `Mutex::is_bootstrapping_done` implemented as `NMTVirtualMemoryTracker::is_bootstrapping_done` as this doesn't really reflect something that Mutex is relying on.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2588844400

From kevinw at openjdk.org  Tue Jan 14 10:13:21 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 14 Jan 2025 10:13:21 GMT
Subject: RFR: 8344966: Remove the allowNonPublic MBean compatibility property
Message-ID: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>

The System Property "jdk.jmx.mbeans.allowNonPublic" was added with JDK-8010285, to optionally be compatible with a time before JDK-8, when Management Interfaces being public was not enforced.

>From JDK-8010285:
_The system property "jdk.jmx.mbeans.allowNonPublic" is used to revert to the old behaviour allowing non-public management interfaces. This property is considered to be transitional and will be removed in the subsequent releases._



That was a long time ago.  This compatibility convenience flag should be removed.

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

Commit messages:
 - 8344966: Remove the allowNonPublic MBean compatibility property

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

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

From coleenp at openjdk.org  Tue Jan 14 16:40:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 16:40:50 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
Message-ID: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.

Tested just now with tier1-4 on x86 and aarch64.

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

Commit messages:
 - Round 1 with the script.

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

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

From sgehwolf at openjdk.org  Tue Jan 14 16:44:41 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Jan 2025 16:44:41 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v15]
In-Reply-To: <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <GOLkliNcZsHseg0QKDaS2qAfzst8-8o6v_Fki4Cmk00=.1b2a2161-018e-4cf1-8e3f-1ea7de174456@github.com>
Message-ID: <QT5oC_368IxeMgaLNzPnJTZatxAkpdta7Svie4upA5o=.913af62b-6e3f-4b2e-bffb-5dfd54f63610@github.com>

On Fri, 10 Jan 2025 14:57:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Add exclusive access dirs directive for systemd tests
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/1f457977...c83c22eb

Keep open, bot.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2590507466

From egahlin at openjdk.org  Tue Jan 14 16:51:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 16:51:37 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <MMmRu1l-43g-NoQK5KQExabzCRfDUXtR8iqVUxKDfWU=.ded60175-9779-4b5e-84be-70a7a64a4a8b@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23109#pullrequestreview-2550409017

From coleenp at openjdk.org  Tue Jan 14 16:56:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 16:56:41 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Thanks Erik.  Trivial?

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590543402

From egahlin at openjdk.org  Tue Jan 14 16:56:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 16:56:41 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
 <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>
Message-ID: <eujrfFEhOFZk-UDG6-5__GkjkY19dxEJPerWhCZv3Q4=.2172be2a-7a7a-4b01-9b04-7a872cd060d7@github.com>

On Tue, 14 Jan 2025 16:51:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks Erik. Trivial?

Yes!

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590556159

From coleenp at openjdk.org  Tue Jan 14 17:03:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 17:03:46 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <MWpMghTHlnYrtsyyoYaen6g9ysHelKqv25P7jL6oxBw=.c87dfec6-fdf5-4a29-9ee3-d87155810f37@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590573131

From coleenp at openjdk.org  Tue Jan 14 17:03:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 17:03:46 GMT
Subject: Integrated: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <ARRecPuvDAI9PCQYTDB44K85IFqQaWEYYdqDy-zVup8=.015e14a4-16ab-485d-9532-4f46d2d620ac@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

This pull request has now been integrated.

Changeset: a01e92cd
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a01e92cdef1b7fb02035f9246a7c9fccfcf46057
Stats:     28 lines in 9 files changed: 0 ins; 0 del; 28 mod

8347724: Replace SIZE_FORMAT in jfr directory

Reviewed-by: egahlin

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

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

From duke at openjdk.org  Tue Jan 14 17:40:20 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 14 Jan 2025 17:40:20 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  revert back to using a flag.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/3fbacd6b..57d0fba0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=15-16

  Stats: 39 lines in 6 files changed: 18 ins; 18 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

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

From duke at openjdk.org  Tue Jan 14 21:36:52 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 14 Jan 2025 21:36:52 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <qxL9i89a6jjanvpXtCO3PSyKrQ3u9M-ssQUv39PgqbQ=.da7dc0c8-2a4d-4586-916c-671753dd363a@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Okay I've gone back to the old approach of using a marker. I've replaced the name `_bootstrapping_done` in favor of `NmtVirtualMemoryLocker::_safe_to_use`. I think this makes more sense because we aren't waiting on NMT bootstrapping, we are instead waiting for other conditions outside of NMT.  

Yes, I agree that this marker should live in NMT instead of Mutex or Threads because we are not only dependent on mutexes being ready or threads being ready, we're dependent on both. And this dependency is specific to NMT (at least it seems for now) since NMT is used so early.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2591146892

From dholmes at openjdk.org  Wed Jan 15 02:15:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Jan 2025 02:15:41 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <MiGwjSqaV9x0rP4PPhxEOEp3b9m9BbzOToyLyTelL2E=.860cf4c3-fe91-4f61-a6cd-1544f9491791@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Nothing further from me. Thanks for your patience and perseverance on this one.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2551424832

From amenkov at openjdk.org  Wed Jan 15 02:33:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 15 Jan 2025 02:33:35 GMT
Subject: RFR: 8344966: Remove the allowNonPublic MBean compatibility
 property
In-Reply-To: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
References: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
Message-ID: <edkDDTrpdMgkMQd25Y3M5nPxvZZswSxCU5OeJ74jUFw=.32493937-61d1-44ff-ad1c-ae232dda001e@github.com>

On Tue, 14 Jan 2025 09:39:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jdk.jmx.mbeans.allowNonPublic" was added with JDK-8010285, to optionally be compatible with a time before JDK-8, when Management Interfaces being public was not enforced.
> 
> From JDK-8010285:
> _The system property "jdk.jmx.mbeans.allowNonPublic" is used to revert to the old behaviour allowing non-public management interfaces. This property is considered to be transitional and will be removed in the subsequent releases._
> 
> 
> 
> That was a long time ago.  This compatibility convenience flag should be removed.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23098#pullrequestreview-2551439688

From stuefe at openjdk.org  Wed Jan 15 06:43:37 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 15 Jan 2025 06:43:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <1nOiSreyP0kY8K5HY02xjtz0gPa7Y9jPqE7lVtSV5T8=.04075331-6448-4351-929e-9c5cc59b84e7@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

This looks good. 

But after the last attempt I would feel safer if we could run this through some more extensive testing. I ran a bunch of tests myself, and will ping the SAP guys. @dholmes-ora could you schedule some tests at Oracle? IIRC the ZGC tests were the ones that broke the most.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2551672289

From syan at openjdk.org  Wed Jan 15 08:37:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Jan 2025 08:37:03 GMT
Subject: RFR: 8347781: Problemlist serviceability/sa/TestJhsdbJstackMixed.java
 on linux-riscv64
Message-ID: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>

Hi all,
We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent fails on linux-riscv64. Should we problemlist this test before the root cause has been fixed.

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

Commit messages:
 - 8347781: Problemlist serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64

Changes: https://git.openjdk.org/jdk/pull/23127/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347781
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/23127.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23127/head:pull/23127

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

From fyang at openjdk.org  Wed Jan 15 08:51:35 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 15 Jan 2025 08:51:35 GMT
Subject: RFR: 8347781: Problemlist
 serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64
In-Reply-To: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
References: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
Message-ID: <6usheGYStPBclzKfBeBunGlOuRe5ZTYzre6gha7KinI=.623adfa8-16e1-4617-a15b-d79aaf26b3a5@github.com>

On Wed, 15 Jan 2025 08:23:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent fails on linux-riscv64. Should we problemlist this test before the root cause has been fixed.

But I never see this failure on SBCs like BPI-F3, Unmatched or Premier P550. On which platform will this trigger?

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

PR Comment: https://git.openjdk.org/jdk/pull/23127#issuecomment-2591967273

From syan at openjdk.org  Wed Jan 15 09:09:38 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Jan 2025 09:09:38 GMT
Subject: RFR: 8347781: Problemlist
 serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64
In-Reply-To: <6usheGYStPBclzKfBeBunGlOuRe5ZTYzre6gha7KinI=.623adfa8-16e1-4617-a15b-d79aaf26b3a5@github.com>
References: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
 <6usheGYStPBclzKfBeBunGlOuRe5ZTYzre6gha7KinI=.623adfa8-16e1-4617-a15b-d79aaf26b3a5@github.com>
Message-ID: <wz-9OI0pKGi-g41L2pxRnYXSwB1p4P_m_ONB0s9KqF0=.58cbe073-9086-439b-84a5-5854f46cbbf4@github.com>

On Wed, 15 Jan 2025 08:47:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

> But I never see this failure on SBCs like BPI-F3, Unmatched or Premier P550. On which platform will this trigger?

My test machine is milk-v. The environment info show as below:


+ uname -a
Linux fedora-riscv-2 6.1.31 #1 SMP Thu Jun 15 01:30:00 CST 2023 riscv64 GNU/Linux
+ cat /etc/os-release
NAME="Fedora Linux"
VERSION="38 (Workstation Edition)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora Linux 38 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f38/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=38
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=38
SUPPORT_END=2024-05-14
VARIANT="Workstation Edition"
VARIANT_ID=workstation
+ lscpu
Architecture:          riscv64
  Byte Order:          Little Endian
CPU(s):                64
  On-line CPU(s) list: 0-63
NUMA:                  
  NUMA node(s):        4
  NUMA node0 CPU(s):   0-7,16-23
  NUMA node1 CPU(s):   8-15,24-31
  NUMA node2 CPU(s):   32-39,48-55
  NUMA node3 CPU(s):   40-47,56-63

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

PR Comment: https://git.openjdk.org/jdk/pull/23127#issuecomment-2592040157

From kevinw at openjdk.org  Wed Jan 15 09:22:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Jan 2025 09:22:34 GMT
Subject: RFR: 8344966: Remove the allowNonPublic MBean compatibility
 property
In-Reply-To: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
References: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
Message-ID: <xPYW3HzKOcAhAqEovlAOpLeCLFAMSZXzAwO-R4WxTio=.a8b42cc8-251a-491b-b5e8-afc0336851c9@github.com>

On Tue, 14 Jan 2025 09:39:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jdk.jmx.mbeans.allowNonPublic" was added with JDK-8010285, to optionally be compatible with a time before JDK-8, when Management Interfaces being public was not enforced.
> 
> From JDK-8010285:
> _The system property "jdk.jmx.mbeans.allowNonPublic" is used to revert to the old behaviour allowing non-public management interfaces. This property is considered to be transitional and will be removed in the subsequent releases._
> 
> 
> 
> That was a long time ago.  This compatibility convenience flag should be removed.

Thanks Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/23098#issuecomment-2592087707

From kevinw at openjdk.org  Wed Jan 15 11:13:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Jan 2025 11:13:05 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility property
Message-ID: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>

Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.

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

Commit messages:
 - 8344969: Remove the jmx.mxbean.multiname compatibility property

Changes: https://git.openjdk.org/jdk/pull/23131/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344969
  Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23131/head:pull/23131

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

From kevinw at openjdk.org  Wed Jan 15 15:04:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Jan 2025 15:04:52 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
Message-ID: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>

The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.

It should be removed.

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

Commit messages:
 - 8344976: Remove the jmx.invoke.getters compatibility property

Changes: https://git.openjdk.org/jdk/pull/23132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344976
  Stats: 64 lines in 2 files changed: 0 ins; 56 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/23132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23132/head:pull/23132

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

From coleenp at openjdk.org  Wed Jan 15 19:35:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 15 Jan 2025 19:35:57 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <G3e6PEnYZwImOskdjoPd73biTEqN3hbRz-p7OfRGatY=.fa6793a3-2718-4129-b0be-cc681e523f1c@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

I'm glad that this could use Mutex in the end and not use the PlatforMutex.  If all else fails though, the way this is structured could use PlatformMutex as the underlying implementation and that would be okay.  Removing the use of ThreadCritical is the motivating part of this change.
I've downloaded the patch and am running tier1-7 on it.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2553722161

From sspitsyn at openjdk.org  Wed Jan 15 19:48:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Jan 2025 19:48:35 GMT
Subject: RFR: 8344966: Remove the allowNonPublic MBean compatibility
 property
In-Reply-To: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
References: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
Message-ID: <QEt_A8xdURtCCfNpX5lvVA0mO7fJ7i5oWmaU__XXDOI=.0c3b598c-4828-4e76-ae88-14f5668f56d1@github.com>

On Tue, 14 Jan 2025 09:39:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jdk.jmx.mbeans.allowNonPublic" was added with JDK-8010285, to optionally be compatible with a time before JDK-8, when Management Interfaces being public was not enforced.
> 
> From JDK-8010285:
> _The system property "jdk.jmx.mbeans.allowNonPublic" is used to revert to the old behaviour allowing non-public management interfaces. This property is considered to be transitional and will be removed in the subsequent releases._
> 
> 
> 
> That was a long time ago.  This compatibility convenience flag should be removed.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23098#pullrequestreview-2553746223

From cjplummer at openjdk.org  Wed Jan 15 20:33:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 Jan 2025 20:33:37 GMT
Subject: RFR: 8347781: Problemlist
 serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64
In-Reply-To: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
References: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
Message-ID: <8VX--0y5pPP_fAlEcNBREp5kyzTZQsltJjRRjNxqvdI=.0799f9f0-dab3-445c-92d6-dd1192f5979d@github.com>

On Wed, 15 Jan 2025 08:23:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent fails on linux-riscv64. Should we problemlist this test before the root cause has been fixed.

Although it's up to the riskv64 maintainers to decide if this should be problem listed or not on riskv64, in general we don't problem list intermittent failures unless they've become too noisy. Although there are no fixed guidelines on when to problem list an intermittent failure, my suggestion would be not to problem list unless it pops up at least every couple of weeks or so with CI testing and there are no plans to fix soon. If it is only showing up in your personal testing and others are not seeing it fail, I would not problem list.

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

PR Comment: https://git.openjdk.org/jdk/pull/23127#issuecomment-2593873620

From duke at openjdk.org  Wed Jan 15 22:30:45 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 22:30:45 GMT
Subject: Withdrawn: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <AJAYVwkH3Ma-yxOCmM0bFSSiFukyr01NVWCAW2YOp_c=.e33de2b1-60db-46f8-9171-8cd2f13c5a64@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

This pull request has been closed without being integrated.

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

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

From sspitsyn at openjdk.org  Wed Jan 15 23:50:43 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Jan 2025 23:50:43 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property
In-Reply-To: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
Message-ID: <UdXrF_bgiU-KLu059fIZSq8HUl-_2VxKneeJemSOzFs=.b0796fe3-06ef-4abf-a9d1-4f6320af6563@github.com>

On Wed, 15 Jan 2025 10:59:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23131#pullrequestreview-2554331035

From lmesnik at openjdk.org  Wed Jan 15 23:53:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Jan 2025 23:53:54 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
Message-ID: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>

There few compiler warning disabled in the testlibary build.
They should be fixed or localized and removed from build to prevent new possible issues.

The main goal is to avoid new such issues in the testlibrary. 
Tested with tier1-5 to ensure that all tests were passed.

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

Commit messages:
 - copyrights updates
 - dangling fixed
 - Merge branch 'master' of https://github.com/openjdk/jdk into warnings
 - restricted removed
 - cast removed
 - deprecation remove
 - try removed
 - preview reviewed
 - serial removed
 - rawtypes removed
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a3be97e2...ae302c9c

Changes: https://git.openjdk.org/jdk/pull/23143/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347840
  Stats: 86 lines in 30 files changed: 23 ins; 4 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/23143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143

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

From amenkov at openjdk.org  Thu Jan 16 01:07:38 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Jan 2025 01:07:38 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property
In-Reply-To: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
Message-ID: <_uoZKFwfxh3qh3QPlrXaHvrqDHxV_pWBqSY-socsCZ4=.3d9402b3-386f-419d-98fb-3b8e53085c92@github.com>

On Wed, 15 Jan 2025 10:59:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.

test/jdk/javax/management/mxbean/SameObjectTwoNamesTest.java line 43:

> 41: 
> 42:     public static void main(String[] args) throws Exception {
> 43:         boolean expectException = true;

I think it would be better to drop this variable at all (and remove unreachable code when the variable is "false")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23131#discussion_r1917527678

From syan at openjdk.org  Thu Jan 16 01:26:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Jan 2025 01:26:50 GMT
Subject: RFR: 8347781: Problemlist
 serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64
In-Reply-To: <8VX--0y5pPP_fAlEcNBREp5kyzTZQsltJjRRjNxqvdI=.0799f9f0-dab3-445c-92d6-dd1192f5979d@github.com>
References: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
 <8VX--0y5pPP_fAlEcNBREp5kyzTZQsltJjRRjNxqvdI=.0799f9f0-dab3-445c-92d6-dd1192f5979d@github.com>
Message-ID: <cUFWmS504rCNFMUjTW6Qf4ZuZZTlqirUrlmRZrgroRA=.d98bd516-b52a-47d7-a881-106ea8867487@github.com>

On Wed, 15 Jan 2025 20:30:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Although it's up to the riskv64 maintainers to decide if this should be problem listed or not on riskv64, in general we don't problem list intermittent failures unless they've become too noisy. Although there are no fixed guidelines on when to problem list an intermittent failure, my suggestion would be not to problem list unless it pops up at least every couple of weeks or so with CI testing and there are no plans to fix soon. If it is only showing up in your personal testing and others are not seeing it fail, I would not problem list.

Thanks your detail explanation. I think I should close this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23127#issuecomment-2594272927

From syan at openjdk.org  Thu Jan 16 01:26:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Jan 2025 01:26:51 GMT
Subject: Withdrawn: 8347781: Problemlist
 serviceability/sa/TestJhsdbJstackMixed.java on linux-riscv64
In-Reply-To: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
References: <qqbG1qSUWxbRwcuaI4S8V7gjFWz47446qFnpUTvgpeA=.a047eb08-6f55-4a8d-a5e1-966f05a71e38@github.com>
Message-ID: <We8ntIYeUmHtIEfGGqIpx4gvYN4KjwaUHvR1fXJCqQs=.98d1df2e-5fa7-4f73-9255-c9a58154ce52@github.com>

On Wed, 15 Jan 2025 08:23:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> We observed the test serviceability/sa/TestJhsdbJstackMixed.java intermittent fails on linux-riscv64. Should we problemlist this test before the root cause has been fixed.

This pull request has been closed without being integrated.

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

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

From dholmes at openjdk.org  Thu Jan 16 06:09:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Jan 2025 06:09:46 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Overall looks good - sometimes a bit of a puzzler understanding what warning is being addressed. :)

Only one thing I'm concerned may be an issue. Also a couple of suggestions.

Thanks

test/lib/jdk/test/lib/format/ArrayDiff.java line 110:

> 108:      * @return an ArrayDiff instance for the two arrays and formatting parameters provided
> 109:      */
> 110:     @SuppressWarnings({"rawtypes", "unchecked"})

Just wondering where the unchecked warning arises in the code?

test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42:

> 40:  *
> 41:  * @author      Bill Foote
> 42:  */

I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment.

test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:

> 44:     public int   getInt(long pos) throws IOException;
> 45:     public long  getLong(long pos) throws IOException;
> 46:     public void  close() throws IOException;

Why was this redefined to throw IOException rather than just Exception?

test/lib/jdk/test/lib/hprof/parser/Reader.java line 96:

> 94:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
> 95:                 // Possible gziped file, try decompress it and get the stack trace.
> 96:                 in.close();

It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

test/lib/jdk/test/lib/hprof/parser/Reader.java line 169:

> 167:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
> 168:                 // Possible gziped file, try decompress it and get the stack trace.
> 169:                 in.close();

It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

test/lib/jdk/test/lib/thread/VThreadRunner.java line 100:

> 98:             if ((X) ex == ex) {
> 99:                 throw (X) ex;
> 100:             }

This doesn't make sense to me.

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

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2554831705
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917773365
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917775999
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917780287
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795069
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917795554
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917787207

From alanb at openjdk.org  Thu Jan 16 07:12:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Jan 2025 07:12:36 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

test/lib/jdk/test/lib/thread/VThreadPinner.java line 97:

> 95:      * virtual thread then it invokes the task directly.
> 96:      */
> 97:     @SuppressWarnings("unchecked")

If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner.

            @SuppressWarnings("unchecked")
            var x = (X) ex;
            throw x;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1917853893

From sspitsyn at openjdk.org  Thu Jan 16 09:20:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Jan 2025 09:20:44 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed
Message-ID: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>

The test lacks a synchronization, so it is added by this fix.

Testing:
 - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
 - TBD: submit mach5 tiers 1-5

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

Commit messages:
 - 8332857: Test vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java failed

Changes: https://git.openjdk.org/jdk/pull/23144/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23144&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332857
  Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23144.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23144/head:pull/23144

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

From kevinw at openjdk.org  Thu Jan 16 09:31:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Jan 2025 09:31:11 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property [v2]
In-Reply-To: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
Message-ID: <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>

> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.

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

  test update/simplification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23131/files
  - new: https://git.openjdk.org/jdk/pull/23131/files/7b85bfbf..3fb85cd4

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

  Stats: 13 lines in 1 file changed: 0 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23131/head:pull/23131

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

From kevinw at openjdk.org  Thu Jan 16 09:31:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Jan 2025 09:31:11 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property [v2]
In-Reply-To: <_uoZKFwfxh3qh3QPlrXaHvrqDHxV_pWBqSY-socsCZ4=.3d9402b3-386f-419d-98fb-3b8e53085c92@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
 <_uoZKFwfxh3qh3QPlrXaHvrqDHxV_pWBqSY-socsCZ4=.3d9402b3-386f-419d-98fb-3b8e53085c92@github.com>
Message-ID: <mvmNpbAjNGe1usiaVpX13l79OQNlXrbT8f58Pkeevss=.b1ac74be-8fcc-4d7d-9aec-9faa8f967fc9@github.com>

On Thu, 16 Jan 2025 01:04:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test update/simplification
>
> test/jdk/javax/management/mxbean/SameObjectTwoNamesTest.java line 43:
> 
>> 41: 
>> 42:     public static void main(String[] args) throws Exception {
>> 43:         boolean expectException = true;
> 
> I think it would be better to drop this variable at all (and remove unreachable code when the variable is "false")

Yes sure, can remove that and simplify this small test - done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23131#discussion_r1918113685

From kevinw at openjdk.org  Thu Jan 16 10:38:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Jan 2025 10:38:07 GMT
Subject: RFR: 8345045: Remove the jmx.remote.x.buffer.size JMX notification
 property
Message-ID: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>

jmx.remote.x.buffer.size was a previous and incorrect name for the jmx.remote.x.notification.buffer.size property.  

The old name was still recognised to aid compatibility.
That was 2004.  We should only recognise the correct name at this point.

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

Commit messages:
 - 8345045: Remove the jmx.remote.x.buffer.size JMX notification property

Changes: https://git.openjdk.org/jdk/pull/23145/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23145&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345045
  Stats: 33 lines in 2 files changed: 0 ins; 24 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/23145.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23145/head:pull/23145

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

From kevinw at openjdk.org  Thu Jan 16 12:38:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Jan 2025 12:38:06 GMT
Subject: RFR: 8345048: Remove the jmx.extend.open.types compatibility property
Message-ID: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>

Classes should not override javax.management.openmbean.OpenType.getClassName(), and this was made illegal (caused an Exception) in JDK6.  A System Property jmx.extend.open.types was introduced to allow such an override, for compatibility reasons.

This was not documented but was mentioned in the Exception message.

This compatibility convenience flag should be removed.

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

Commit messages:
 - 8345048: Remove the jmx.extend.open.types compatibility property

Changes: https://git.openjdk.org/jdk/pull/23151/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345048
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23151.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23151/head:pull/23151

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

From kevinw at openjdk.org  Thu Jan 16 13:11:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Jan 2025 13:11:08 GMT
Subject: RFR: 8345049: Remove the jmx.tabular.data.hash.map compatibility
 property
Message-ID: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>

Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

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

Commit messages:
 - 8345049: Remove the jmx.tabular.data.hash.map compatibility property

Changes: https://git.openjdk.org/jdk/pull/23153/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23153&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345049
  Stats: 50 lines in 2 files changed: 0 ins; 47 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/23153.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23153/head:pull/23153

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

From lmesnik at openjdk.org  Thu Jan 16 18:09:59 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:09:59 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v2]
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <6Nzo-XUtQRZNsZlfAmV8-4tF36VpdbUamSV195gwQ1g=.7f8807ad-d00e-487a-9c4a-12ebc7be7676@github.com>

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23143/files
  - new: https://git.openjdk.org/jdk/pull/23143/files/ae302c9c..6a23012e

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

  Stats: 52 lines in 10 files changed: 6 ins; 42 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23143/head:pull/23143

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

From lmesnik at openjdk.org  Thu Jan 16 18:18:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:16 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
Message-ID: <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>

On Thu, 16 Jan 2025 05:31:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert change
>
> test/lib/jdk/test/lib/format/ArrayDiff.java line 110:
> 
>> 108:      * @return an ArrayDiff instance for the two arrays and formatting parameters provided
>> 109:      */
>> 110:     @SuppressWarnings({"rawtypes", "unchecked"})
> 
> Just wondering where the unchecked warning arises in the code?

It is in the line 123.

> test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java line 42:
> 
>> 40:  *
>> 41:  * @author      Bill Foote
>> 42:  */
> 
> I would suggest deleting any comment blocks that just have the @author tag, and deleting the @author elsewhere. All these files (lib/hprof) already have an author attribution comment.

done

> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:
> 
>> 44:     public int   getInt(long pos) throws IOException;
>> 45:     public long  getLong(long pos) throws IOException;
>> 46:     public void  close() throws IOException;
> 
> Why was this redefined to throw IOException rather than just Exception?

The javac complains about potential InterruptedException, so I changed type.
See
https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
`Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.`

> test/lib/jdk/test/lib/hprof/parser/Reader.java line 96:
> 
>> 94:             } else if ((i >>> 8) == GZIP_HEADER_MAGIC) {
>> 95:                 // Possible gziped file, try decompress it and get the stack trace.
>> 96:                 String deCompressedFile = "heapdump" + System.currentTimeMillis() + ".hprof";
> 
> It is not obvious to me that there may not be a reason for closing all of the streams before opening new ones below.

Thanks for catching this. I missed that we try to re-open the same fail in else branch.

> test/lib/jdk/test/lib/thread/VThreadRunner.java line 100:
> 
>> 98:             if ((X) ex == ex) {
>> 99:                 throw (X) ex;
>> 100:             }
> 
> This doesn't make sense to me.

Sorry for mess, this shouldn't have been committed at all, just some drafting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918956737
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918960995
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918969394
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918976104
PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918981965

From lmesnik at openjdk.org  Thu Jan 16 18:18:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:15 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23143/files
  - new: https://git.openjdk.org/jdk/pull/23143/files/6a23012e..7a1c35da

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

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

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

From lmesnik at openjdk.org  Thu Jan 16 18:18:16 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:16 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <ZzZgrVk1z_5JOOT-3buuPQ-kj_PhXx0iOzpVolbtJLc=.419a6c89-71c4-4342-94fa-54775c63a873@github.com>
Message-ID: <iRy6PrTfmonHd0LfREsBdkaYwuL4JI3IpopvbU4tGjs=.cd67878c-a8ec-4f4d-9cfa-4b9dde8a8d85@github.com>

On Thu, 16 Jan 2025 07:09:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert change
>
> test/lib/jdk/test/lib/thread/VThreadPinner.java line 97:
> 
>> 95:      * virtual thread then it invokes the task directly.
>> 96:      */
>> 97:     @SuppressWarnings("unchecked")
> 
> If you change the code to the follow, same in VThreadRunner then it would avoid the the SW on the method and avoid the other change you have to VThreadRunner.
> 
>             @SuppressWarnings("unchecked")
>             var x = (X) ex;
>             throw x;

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1918978915

From lmesnik at openjdk.org  Thu Jan 16 18:18:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Jan 2025 18:18:15 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
Message-ID: <k-KYhhMc4dL_1XfJcYgPWdiUGmx0EgwKrFtiEd2UX_s=.82e63bcd-fd17-474e-a66b-07e0aeb0ec30@github.com>

On Thu, 16 Jan 2025 18:14:39 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There few compiler warning disabled in the testlibary build.
>> They should be fixed or localized and removed from build to prevent new possible issues.
>> 
>> The main goal is to avoid new such issues in the testlibrary. 
>> Tested with tier1-5 to ensure that all tests were passed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change

See answer and updated vewrsion.

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

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2556833136

From cjplummer at openjdk.org  Thu Jan 16 19:31:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Jan 2025 19:31:36 GMT
Subject: RFR: 8345049: Remove the jmx.tabular.data.hash.map compatibility
 property
In-Reply-To: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
References: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
Message-ID: <Lo6rSGrqqwX3LSFfkd_b0PK8Mv8uRL2tn2KCBR1R6Xs=.b77ecaa4-e256-4f5b-be74-8da16fbb6cef@github.com>

On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23153#pullrequestreview-2557099056

From coleenp at openjdk.org  Thu Jan 16 20:14:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 16 Jan 2025 20:14:15 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
Message-ID: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
Tested with tier1-4.

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

Commit messages:
 - More formatting changes
 - Changes made by hand
 - Replace SIZE_FORMAT in runtime

Changes: https://git.openjdk.org/jdk/pull/23160/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347733
  Stats: 341 lines in 68 files changed: 3 ins; 6 del; 332 mod
  Patch: https://git.openjdk.org/jdk/pull/23160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23160/head:pull/23160

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

From cjplummer at openjdk.org  Thu Jan 16 20:34:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Jan 2025 20:34:38 GMT
Subject: RFR: 8345048: Remove the jmx.extend.open.types compatibility
 property
In-Reply-To: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
References: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
Message-ID: <-KCXPzziTer6iK4ZQOhgTfPPaWZ4oAb6oJgngKJ8xgA=.6a30e3f0-18a4-4701-9bb1-abb7f767e1fb@github.com>

On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Classes should not override javax.management.openmbean.OpenType.getClassName(), and this was made illegal (caused an Exception) in JDK6.  A System Property jmx.extend.open.types was introduced to allow such an override, for compatibility reasons.
> 
> This was not documented but was mentioned in the Exception message.
> 
> This compatibility convenience flag should be removed.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23151#pullrequestreview-2557236847

From amenkov at openjdk.org  Thu Jan 16 20:42:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Jan 2025 20:42:35 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed
In-Reply-To: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
Message-ID: <rw2ceCsM0pSmaTfgsI_-qSFYwRHbT4XonShto0TiUOk=.4db01464-ccd0-49c6-9f9f-dd9537c1ef46@github.com>

On Thu, 16 Jan 2025 09:15:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test lacks a synchronization, so it is added by this fix.
> 
> Testing:
>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>  - TBD: submit mach5 tiers 1-5

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23144#pullrequestreview-2557249017

From amenkov at openjdk.org  Thu Jan 16 21:00:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Jan 2025 21:00:33 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property [v2]
In-Reply-To: <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
 <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
Message-ID: <pOr0SWW4D4oHWMMAuD6eXKf7NR4Pks9qhVUcsKjrEeA=.e25142bb-59cb-4405-bda5-51060fc84b96@github.com>

On Thu, 16 Jan 2025 09:31:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update/simplification

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23131#pullrequestreview-2557262468

From amenkov at openjdk.org  Thu Jan 16 21:02:49 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Jan 2025 21:02:49 GMT
Subject: RFR: 8345045: Remove the jmx.remote.x.buffer.size JMX notification
 property
In-Reply-To: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
References: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
Message-ID: <eRZ89AUT4c7geEVQy5EEP5m3VMwKK8tL_HoXOau_clQ=.5e1d7762-3758-454b-997a-fbc9ae45a6a9@github.com>

On Thu, 16 Jan 2025 10:31:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> jmx.remote.x.buffer.size was a previous and incorrect name for the jmx.remote.x.notification.buffer.size property.  
> 
> The old name was still recognised to aid compatibility.
> That was 2004.  We should only recognise the correct name at this point.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23145#pullrequestreview-2557282832

From amenkov at openjdk.org  Thu Jan 16 21:09:47 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Jan 2025 21:09:47 GMT
Subject: RFR: 8345048: Remove the jmx.extend.open.types compatibility
 property
In-Reply-To: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
References: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
Message-ID: <iq9T-F6vrdIWxt8OcCww9HezI2vg1Qptj-e7BkijeZ4=.d88ee61e-9952-4bc5-8a35-7633d812e9b2@github.com>

On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Classes should not override javax.management.openmbean.OpenType.getClassName(), and this was made illegal (caused an Exception) in JDK6.  A System Property jmx.extend.open.types was introduced to allow such an override, for compatibility reasons.
> 
> This was not documented but was mentioned in the Exception message.
> 
> This compatibility convenience flag should be removed.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23151#pullrequestreview-2557293584

From cjplummer at openjdk.org  Thu Jan 16 22:42:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Jan 2025 22:42:35 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed
In-Reply-To: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
Message-ID: <kHDD-TGP5zecoNjAxtnpovs9IrW4iknnzpvDMJN6v-c=.78ee61f6-c9ce-4a4a-b026-adad8d5b743a@github.com>

On Thu, 16 Jan 2025 09:15:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test lacks a synchronization, so it is added by this fix.
> 
> Testing:
>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>  - TBD: submit mach5 tiers 1-5

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.cpp line 36:

> 34: 
> 35: static jlong timeout = 0;
> 36: static jrawMonitorID monitor;

Can you clarify which data this monitor is protecting? I think it is just prevTestedThreadTime and prevAgentThreadTime, in which case I think you should refine its usage. For example, is it really needed in any of the callbacks other than callbackThreadStart()?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23144#discussion_r1919331328

From zgu at openjdk.org  Fri Jan 17 01:11:44 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 17 Jan 2025 01:11:44 GMT
Subject: RFR: 8347959: ThreadDumper leaks memory
Message-ID: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>

It leaks _frames array and frames stored inside the array

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

Commit messages:
 - 8347959: ThreadDumper leaks memory

Changes: https://git.openjdk.org/jdk/pull/23169/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23169&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347959
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23169/head:pull/23169

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

From sspitsyn at openjdk.org  Fri Jan 17 02:01:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 02:01:50 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed
In-Reply-To: <kHDD-TGP5zecoNjAxtnpovs9IrW4iknnzpvDMJN6v-c=.78ee61f6-c9ce-4a4a-b026-adad8d5b743a@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <kHDD-TGP5zecoNjAxtnpovs9IrW4iknnzpvDMJN6v-c=.78ee61f6-c9ce-4a4a-b026-adad8d5b743a@github.com>
Message-ID: <SAWa3im7OwMXhmJERdesc3vvSmaBtaxNWkVXWu0adZI=.bcc2b952-ac76-4e89-9cd8-4d7f741e567a@github.com>

On Thu, 16 Jan 2025 22:39:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The test lacks a synchronization, so it is added by this fix.
>> 
>> Testing:
>>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>>  - TBD: submit mach5 tiers 1-5
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/thrcputime002.cpp line 36:
> 
>> 34: 
>> 35: static jlong timeout = 0;
>> 36: static jrawMonitorID monitor;
> 
> Can you clarify which data this monitor is protecting? I think it is just prevTestedThreadTime and prevAgentThreadTime, in which case I think you should refine its usage. For example, is it really needed in any of the callbacks other than callbackThreadStart()?

My intention is to serialize event callback calls plus protect multi-threaded access/modification of these variables.
I can add a comment with this clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23144#discussion_r1919452824

From amenkov at openjdk.org  Fri Jan 17 02:08:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 Jan 2025 02:08:35 GMT
Subject: RFR: 8347959: ThreadDumper leaks memory
In-Reply-To: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
References: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
Message-ID: <q4PIunsew1JHERrHBm6UO_3bezWMht-KudwPgbYIwCQ=.193f1bee-d746-4f5a-8fd8-6c997a245ed7@github.com>

On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It leaks _frames array and frames stored inside the array

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23169#pullrequestreview-2557823941

From sspitsyn at openjdk.org  Fri Jan 17 02:09:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 02:09:54 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
Message-ID: <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>

> The test lacks a synchronization, so it is added by this fix.
> 
> Testing:
>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>  - TBD: submit mach5 tiers 1-5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add a clarifying comment to monitor declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23144/files
  - new: https://git.openjdk.org/jdk/pull/23144/files/ec07eda1..3c503c5b

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

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

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

From sspitsyn at openjdk.org  Fri Jan 17 03:19:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 03:19:35 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property [v2]
In-Reply-To: <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
 <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
Message-ID: <zh8sPd46dxhCvAxiCLuqDxzrQSJNK-Ba32o9EmOtI1A=.0fd484fb-8228-4079-92e1-18dcfd1e0640@github.com>

On Thu, 16 Jan 2025 09:31:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update/simplification

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23131#pullrequestreview-2557880547

From sspitsyn at openjdk.org  Fri Jan 17 03:22:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 03:22:39 GMT
Subject: RFR: 8345048: Remove the jmx.extend.open.types compatibility
 property
In-Reply-To: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
References: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
Message-ID: <ADwmDuUgAl98brEaub2WpKNShcRQzKjMONT50Socnv8=.92e9ddab-7268-4135-8df9-8d0e92c28dd2@github.com>

On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Classes should not override javax.management.openmbean.OpenType.getClassName(), and this was made illegal (caused an Exception) in JDK6.  A System Property jmx.extend.open.types was introduced to allow such an override, for compatibility reasons.
> 
> This was not documented but was mentioned in the Exception message.
> 
> This compatibility convenience flag should be removed.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23151#pullrequestreview-2557884379

From sspitsyn at openjdk.org  Fri Jan 17 03:33:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 03:33:40 GMT
Subject: RFR: 8345045: Remove the jmx.remote.x.buffer.size JMX notification
 property
In-Reply-To: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
References: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
Message-ID: <UcTZW2fIqNmt_KD3E6wGceVGnEL8kDjsOj9NSvuEFXU=.4e21233f-5628-471e-8cbd-0bb249288a86@github.com>

On Thu, 16 Jan 2025 10:31:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> jmx.remote.x.buffer.size was a previous and incorrect name for the jmx.remote.x.notification.buffer.size property.  
> 
> The old name was still recognised to aid compatibility.
> That was 2004.  We should only recognise the correct name at this point.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23145#pullrequestreview-2557893106

From sspitsyn at openjdk.org  Fri Jan 17 03:38:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 03:38:34 GMT
Subject: RFR: 8345049: Remove the jmx.tabular.data.hash.map compatibility
 property
In-Reply-To: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
References: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
Message-ID: <3Ag-r8FPbncVeulSEIC6ycxcltH6dFCf8TjFPcQ5MRA=.fa563fb0-0e50-41fe-be1b-2c35754399f6@github.com>

On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23153#pullrequestreview-2557896388

From sspitsyn at openjdk.org  Fri Jan 17 03:48:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 03:48:34 GMT
Subject: RFR: 8347959: ThreadDumper leaks memory
In-Reply-To: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
References: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
Message-ID: <NtzYbT6V2DxsIa2LvLaR_lInYs6xMdYILvd_p4k72SE=.99a9464d-919e-4a72-b1a9-c963d58a80f3@github.com>

On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It leaks _frames array and frames stored inside the array

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23169#pullrequestreview-2557904693

From sspitsyn at openjdk.org  Fri Jan 17 04:09:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 04:09:34 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

This makes code more readable. Looks good.
I've not checked the copyright years.

src/hotspot/share/oops/array.hpp line 77:

> 75: 
> 76:     size_t elements = left / sizeof(T);
> 77:     assert(elements <= (size_t)INT_MAX, "number of elements %zudoesn't fit into an int.", elements);

Nit: It seems that a space is needed after `%zu`. This was this way originally.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2557917156
PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1919521203

From dholmes at openjdk.org  Fri Jan 17 05:12:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 05:12:34 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <FfED-EHugBDXMLN6AdLQ_GLo45J1S6Cwe-4DiHc3_g8=.e743ceb4-aa6e-4d28-b864-5fb2ea9c6e7b@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

LGTM.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2557979828

From dholmes at openjdk.org  Fri Jan 17 06:01:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 06:01:48 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <gbUWzuCDmYFaDYRNiXpVNl40brKXPb8PDatkR7B5l-o=.06873e91-c20a-4a24-a058-9c4830df1c80@github.com>
Message-ID: <o33EsykK6J5km_i1bsx-syIBmu2EXlmxhCSfyLaaQ2U=.1e20bd92-24ba-49ed-ae75-bb758adeaf6a@github.com>

On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There few compiler warning disabled in the testlibary build.
>> They should be fixed or localized and removed from build to prevent new possible issues.
>> 
>> The main goal is to avoid new such issues in the testlibrary. 
>> Tested with tier1-5 to ensure that all tests were passed.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert change

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23143#pullrequestreview-2558035645

From dholmes at openjdk.org  Fri Jan 17 06:01:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Jan 2025 06:01:49 GMT
Subject: RFR: 8347840: Fix testlibrary compilation warnings [v3]
In-Reply-To: <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
 <lsAg7A_4Wkr7BWfLvnphoYVU1Fjh0TtwJZJesLHZYFo=.c95180c4-2970-48a2-95ca-ccf26c2b61b4@github.com>
 <QS-YajV1x0vqI7pvgnMti4iaKWtzPoGmEweNyCEoGMA=.b5fcd363-9295-456e-b7ba-dfa729e0f65b@github.com>
Message-ID: <nfwHCq1DfAO6Zgauc0oa0kRSy1Cqft87VqZfPjIpfhw=.0e9d2c45-54e4-44dc-a861-d0b1ba51271a@github.com>

On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:
>> 
>>> 44:     public int   getInt(long pos) throws IOException;
>>> 45:     public long  getLong(long pos) throws IOException;
>>> 46:     public void  close() throws IOException;
>> 
>> Why was this redefined to throw IOException rather than just Exception?
>
> The javac complains about potential InterruptedException, so I changed type.
> See
> https://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html
> `Implementers of this interface are also strongly advised to not have the close method throw [InterruptedException](https://docs.oracle.com/javase/8/docs/api/java/lang/InterruptedException.html). This exception interacts with a thread's interrupted status, and runtime misbehavior is likely to occur if an InterruptedException is [suppressed](https://docs.oracle.com/javase/8/docs/api/java/lang/Throwable.html#addSuppressed-java.lang.Throwable-). More generally, if it would cause problems for an exception to be suppressed, the AutoCloseable.close method should not throw it.`

Ugggh! That is an annoyance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23143#discussion_r1919602558

From shade at openjdk.org  Fri Jan 17 08:02:35 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 17 Jan 2025 08:02:35 GMT
Subject: RFR: 8347959: ThreadDumper leaks memory
In-Reply-To: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
References: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
Message-ID: <UScOojLgpA8o3TpYM8X6Aq3ATmdZ_1PKD5qrCykY5Bw=.288d8955-cc57-4547-aa18-2b984396b4bc@github.com>

On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It leaks _frames array and frames stored inside the array

Looks fine. Good catch!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23169#pullrequestreview-2558194203

From coleenp at openjdk.org  Fri Jan 17 12:18:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 12:18:52 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Added the needed blank.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23160/files
  - new: https://git.openjdk.org/jdk/pull/23160/files/87fdb72f..c646de2d

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

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

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

From coleenp at openjdk.org  Fri Jan 17 12:18:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 12:18:52 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <t4eG8WFq2zfyOk8f-50NQfaMSN6VRSwTA8Zkd7worZ0=.bc702046-7e9c-4e4d-86cf-7f245bc0f058@github.com>
Message-ID: <G3Er8sZIxdK7xTk9U13W7HjD-Vtmq8zH45ASZV2RZJk=.f6210dc4-e7ce-428f-af04-89003f3f0739@github.com>

On Fri, 17 Jan 2025 04:00:18 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added the needed blank.
>
> src/hotspot/share/oops/array.hpp line 77:
> 
>> 75: 
>> 76:     size_t elements = left / sizeof(T);
>> 77:     assert(elements <= (size_t)INT_MAX, "number of elements %zudoesn't fit into an int.", elements);
> 
> Nit: It seems that a space is needed after `%zu`. This was this way originally.

I added the space, since you read through carefully enough to see it.  Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920107348

From zgu at openjdk.org  Fri Jan 17 13:41:39 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 17 Jan 2025 13:41:39 GMT
Subject: RFR: 8347959: ThreadDumper leaks memory
In-Reply-To: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
References: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
Message-ID: <n-GWngfruYRfs8GfmdVb0XOIKYqbeq27s0A6XeNr6p4=.b891ffe2-2e07-4feb-82d7-a2ecbc450ecd@github.com>

On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It leaks _frames array and frames stored inside the array

Thanks, @alexmenkov @sspitsyn  @shipilev

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

PR Comment: https://git.openjdk.org/jdk/pull/23169#issuecomment-2598388660

From zgu at openjdk.org  Fri Jan 17 13:41:40 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 17 Jan 2025 13:41:40 GMT
Subject: Integrated: 8347959: ThreadDumper leaks memory
In-Reply-To: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
References: <VGCzsjtivcn8vPwO8qeUMVOC8qbXR0vZjwsSDa-Ofcg=.38c83689-0880-4be5-9259-af0272eb884e@github.com>
Message-ID: <Wmfo8EG-Sn209TT5IPaHKJ5dGkvBSy08FD9DzOzW1lY=.66426f2b-2674-46c5-a324-9d4cf4044425@github.com>

On Fri, 17 Jan 2025 01:07:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It leaks _frames array and frames stored inside the array

This pull request has now been integrated.

Changeset: 2c41f5ad
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c41f5adbfcebb057c2ffc8396729bdd1c100079
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8347959: ThreadDumper leaks memory

Reviewed-by: amenkov, sspitsyn, shade

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

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

From coleenp at openjdk.org  Fri Jan 17 13:51:38 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 13:51:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <jHXmlfEjYUya7xtaqiYVhlpjL1CrkDTiSRJgHtqToJE=.0e33ebfe-6ef6-4405-b3f2-fc07c6b520b6@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

I reran our internal tests tier1-7 on this change and they all passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598408532

From dfuchs at openjdk.org  Fri Jan 17 14:22:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 17 Jan 2025 14:22:38 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl
In-Reply-To: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
Message-ID: <TcxHgQ8NYdpri9pqZazlbHQlBpBwK0CFA2qWW6s8ZYo=.12506050-5ea7-4462-a53b-486ab9f9d7c3@github.com>

On Mon, 13 Jan 2025 13:56:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is a post-SecurityManager-removal cleanup, following-on from:
> 
> 8344394: Remove SecurityManager and related calls from java.management.rmi 
> 
> 
> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
> Remove wrapping of Exceptions in PrivilegedActionException.
> 
> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.

Changes requested by dfuchs (Reviewer).

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 212:

> 210:                 throw (SecurityException) e;
> 211:             if (e instanceof RuntimeException)
> 212:                 throw (RuntimeException) e;

Throughout all these changes: SecurityException is  a RuntimeException, so you do not need to check for both.

An alternative is to:

} catch (RuntimeException r) {
    throw r;
} catch (Exception e) {
    ....
}

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

PR Review: https://git.openjdk.org/jdk/pull/23072#pullrequestreview-2559138986
PR Review Comment: https://git.openjdk.org/jdk/pull/23072#discussion_r1920262189

From duke at openjdk.org  Fri Jan 17 14:41:38 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 17 Jan 2025 14:41:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Thank you everyone for your feedback and time reviewing this!

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598509189

From duke at openjdk.org  Fri Jan 17 14:41:39 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Jan 2025 14:41:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <yuKDaZnvBXvb06vkHPpzUk9a-AgBuH1KHFr8_RWc1fo=.f261eb1e-4f20-4bb1-8f42-7258a9a20416@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

@roberttoyonaga 
Your change (at version 57d0fba0f8abaa1afaf42c5380770adc80d20a0d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598511295

From matsaave at openjdk.org  Fri Jan 17 15:02:41 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 17 Jan 2025 15:02:41 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
Message-ID: <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>

On Fri, 17 Jan 2025 12:18:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the needed blank.

Changes look good!

src/hotspot/share/utilities/globalDefinitions.hpp line 137:

> 135: #define UINT64_FORMAT_0          "%016"       PRIx64
> 136: 
> 137: 

Extra newline added here, was that on purpose?

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

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23160#pullrequestreview-2559235603
PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920318853

From stuefe at openjdk.org  Fri Jan 17 15:12:38 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 17 Jan 2025 15:12:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
 <WEiFAz-FShZOwNi18bW4sNlJ6o4L62hJ0W_59bbhCLc=.972d8c09-cad5-423c-b0f4-e2229d64fec9@github.com>
Message-ID: <ixNGddhDA_Rv9EOvzjVdjLKB89Ufw8P-yPd6uuUqANg=.eed96e42-9018-4921-bb7f-27857e317a0e@github.com>

On Fri, 17 Jan 2025 14:37:49 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert back to using a flag.
>
> Thank you everyone for your feedback and time reviewing this!

@roberttoyonaga Hold off, I still wait for the SAP people to report back with their tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2598574044

From lmesnik at openjdk.org  Fri Jan 17 15:45:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 15:45:49 GMT
Subject: Integrated: 8347840: Fix testlibrary compilation warnings
In-Reply-To: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
References: <mlJivWt3tEbM7mPmX-Y4OrvH9DW43NInpyuSH0-ZI7E=.2e0ce151-1f26-4a8f-9250-e97037a1d881@github.com>
Message-ID: <u7VnWMvtDBNYJIVxaVgjlaGgU5QhleZEEPfFtt5KXiM=.4916d0dd-7d9b-4255-ab0c-1e673451c50c@github.com>

On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new possible issues.
> 
> The main goal is to avoid new such issues in the testlibrary. 
> Tested with tier1-5 to ensure that all tests were passed.

This pull request has now been integrated.

Changeset: 2ca1b4d4
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ca1b4d48da7eb9b5baf0ac213f3ce87f47dd316
Stats:     120 lines in 30 files changed: 25 ins; 42 del; 53 mod

8347840: Fix testlibrary compilation warnings

Reviewed-by: dholmes

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

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

From coleenp at openjdk.org  Fri Jan 17 16:27:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:44 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
Message-ID: <9wf10scKR45T8HuK0DSglfRB8geI79INMllteJGJufM=.4c8e945e-8400-42ab-993d-2b69bb4d1d81@github.com>

On Fri, 17 Jan 2025 12:18:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the needed blank.

Thank you for reviewing Serguei, David and Matias.

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

PR Comment: https://git.openjdk.org/jdk/pull/23160#issuecomment-2598723117

From coleenp at openjdk.org  Fri Jan 17 16:27:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:46 GMT
Subject: Integrated: 8347733: Replace SIZE_FORMAT in runtime code
In-Reply-To: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
Message-ID: <DkLD4hdmeV3Av9gG4Se2tlBDGXUay5cCYLGxyisNuLE=.8257c7ba-5534-4c04-bd5b-68737600b0c7@github.com>

On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the runtime code.  The second and third commits are hand editing for fixing up formats of the code, not the output.  After this, there'll be a separate change to remove SIZE_FORMAT.  Note that SIZE_FORMAT_X_0 depends on LP64 so that macro will be retained.  There were a couple of compiler files that I missed.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: baca7daa
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baca7daa32d553b647bdb33bb74a0eb84542deeb
Stats:     341 lines in 68 files changed: 3 ins; 6 del; 332 mod

8347733: Replace SIZE_FORMAT in runtime code

Reviewed-by: matsaave, sspitsyn, dholmes

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

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

From coleenp at openjdk.org  Fri Jan 17 16:27:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jan 2025 16:27:45 GMT
Subject: RFR: 8347733: Replace SIZE_FORMAT in runtime code [v2]
In-Reply-To: <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>
References: <-oqzIxipfJpi-kjeXKVYE-5qw9-sbttma_2GqwrOiIk=.8a5a5106-4823-48dc-930c-14efcb847c9d@github.com>
 <LWIRLaYe2qZLV3Sa5ZGoODRS1bwYBnpWp4YkNkWDWuQ=.68bd7b3f-7a0a-40f3-bf8e-c8172dd206b1@github.com>
 <I2SjOxy8Z_lIxUiHHivS7yc4xXIyXuagiMiMJaPtjL4=.1cca72fa-5d61-4baf-8e91-453f9350514d@github.com>
Message-ID: <EmAb1l4mXm1ntE11cNZeMZ-AT4dDnAlbIsm2mCPadxI=.08fecc30-9216-4355-825c-557c1ece4d90@github.com>

On Fri, 17 Jan 2025 14:59:33 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added the needed blank.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 137:
> 
>> 135: #define UINT64_FORMAT_0          "%016"       PRIx64
>> 136: 
>> 137: 
> 
> Extra newline added here, was that on purpose?

No it wasn't on purpose.  I can clean this up when sending out the PR for JDK-8347990.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23160#discussion_r1920437819

From kevinw at openjdk.org  Fri Jan 17 17:39:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Jan 2025 17:39:55 GMT
Subject: RFR: 8347985: Deprecate java.management Permission classes for removal
Message-ID: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>

Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.  This change is for those in the java.management module.

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

Commit messages:
 - 8347985: Deprecate java.management Permission classes for removal

Changes: https://git.openjdk.org/jdk/pull/23178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347985
  Stats: 31 lines in 5 files changed: 25 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23178/head:pull/23178

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

From kevinw at openjdk.org  Fri Jan 17 18:21:36 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Jan 2025 18:21:36 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl
In-Reply-To: <TcxHgQ8NYdpri9pqZazlbHQlBpBwK0CFA2qWW6s8ZYo=.12506050-5ea7-4462-a53b-486ab9f9d7c3@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <TcxHgQ8NYdpri9pqZazlbHQlBpBwK0CFA2qWW6s8ZYo=.12506050-5ea7-4462-a53b-486ab9f9d7c3@github.com>
Message-ID: <4TTQRMhMKVNtHzJiggQCZgoLQE2xlPJZVAryHYnwffc=.d885cf7a-a77e-46ac-bd3c-447c8cc0133a@github.com>

On Fri, 17 Jan 2025 14:19:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a post-SecurityManager-removal cleanup, following-on from:
>> 
>> 8344394: Remove SecurityManager and related calls from java.management.rmi 
>> 
>> 
>> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
>> Remove wrapping of Exceptions in PrivilegedActionException.
>> 
>> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 212:
> 
>> 210:                 throw (SecurityException) e;
>> 211:             if (e instanceof RuntimeException)
>> 212:                 throw (RuntimeException) e;
> 
> Throughout all these changes: SecurityException is  a RuntimeException, so you do not need to check for both.
> 
> An alternative is to:
> 
> } catch (RuntimeException r) {
>     throw r;
> } catch (Exception e) {
>     ....
> }

OK sure, I was just making it super explicit.  Can update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23072#discussion_r1920580855

From kevinw at openjdk.org  Fri Jan 17 19:14:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Jan 2025 19:14:13 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v2]
In-Reply-To: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
Message-ID: <NldnZBgZdM_gShMsZWmsvyflaDgMUES2sNFhf9AF8WE=.d9c6b6ab-b8d2-4269-8f38-ca02112a8f30@github.com>

> This is a post-SecurityManager-removal cleanup, following-on from:
> 
> 8344394: Remove SecurityManager and related calls from java.management.rmi 
> 
> 
> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
> Remove wrapping of Exceptions in PrivilegedActionException.
> 
> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Remove unnecessary/dup catches
 - Merge remote-tracking branch 'upstream/master' into 8345079_RMIConnectionImpl_excep
 - unnecessary catches
 - (c)
 - 8345079: Simplify/cleanup Exception handling in RMIConnectionImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23072/files
  - new: https://git.openjdk.org/jdk/pull/23072/files/cc4dcd0b..0f06f752

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

  Stats: 18608 lines in 979 files changed: 9068 ins; 4285 del; 5255 mod
  Patch: https://git.openjdk.org/jdk/pull/23072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23072/head:pull/23072

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

From kevinw at openjdk.org  Fri Jan 17 19:16:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Jan 2025 19:16:35 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v2]
In-Reply-To: <4TTQRMhMKVNtHzJiggQCZgoLQE2xlPJZVAryHYnwffc=.d885cf7a-a77e-46ac-bd3c-447c8cc0133a@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <TcxHgQ8NYdpri9pqZazlbHQlBpBwK0CFA2qWW6s8ZYo=.12506050-5ea7-4462-a53b-486ab9f9d7c3@github.com>
 <4TTQRMhMKVNtHzJiggQCZgoLQE2xlPJZVAryHYnwffc=.d885cf7a-a77e-46ac-bd3c-447c8cc0133a@github.com>
Message-ID: <UKlVJ9aoD9ZuyevR1ZVrFxsrA0SLH2J4oSXEABsp95Q=.c45402e6-9481-4e73-8616-70200981aa64@github.com>

On Fri, 17 Jan 2025 18:18:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 212:
>> 
>>> 210:                 throw (SecurityException) e;
>>> 211:             if (e instanceof RuntimeException)
>>> 212:                 throw (RuntimeException) e;
>> 
>> Throughout all these changes: SecurityException is  a RuntimeException, so you do not need to check for both.
>> 
>> An alternative is to:
>> 
>> } catch (RuntimeException r) {
>>     throw r;
>> } catch (Exception e) {
>>     ....
>> }
>
> OK sure, I was just making it super explicit.  Can update.

Updated - re-ran all of the management tests, looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23072#discussion_r1920640875

From lmesnik at openjdk.org  Fri Jan 17 20:10:36 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Jan 2025 20:10:36 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
Message-ID: <TU9InfBUnO-7lvJWx3C6q8bGUehktFsw5RZjDbr6HTY=.5e0ca81c-358a-481a-90b6-1fe6116dbc33@github.com>

On Fri, 17 Jan 2025 02:09:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test lacks a synchronization, so it is added by this fix.
>> 
>> Testing:
>>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>>  - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a clarifying comment to monitor declaration

It is a good improvement of test stability. However, I am not sure that it fixed test problem.

Can the test fails because clock on the host were changed? There are some similar test failures happened when host update clock time during test execution.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23144#pullrequestreview-2559877062

From sspitsyn at openjdk.org  Fri Jan 17 20:50:37 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 20:50:37 GMT
Subject: RFR: 8347985: Deprecate java.management Permission classes for
 removal
In-Reply-To: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
References: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
Message-ID: <DjntSUCpRgrmgBoqpDKUFJ9643mhVSl8vaODfZVvPac=.af531992-7ce1-4f16-8dec-289b8f7f795a@github.com>

On Fri, 17 Jan 2025 17:27:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.  This change is for those in the java.management module.

This looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23178#pullrequestreview-2559931139

From sspitsyn at openjdk.org  Fri Jan 17 20:59:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 20:59:40 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
Message-ID: <ivu6eKDmrmBigLFpokA244RxGTZrKzicsds-XK-EF9k=.dfcf2641-e9da-4ef3-8443-b11f69a5e0cb@github.com>

On Fri, 17 Jan 2025 02:09:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test lacks a synchronization, so it is added by this fix.
>> 
>> Testing:
>>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>>  - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a clarifying comment to monitor declaration

Alex and Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23144#issuecomment-2599185365

From sspitsyn at openjdk.org  Fri Jan 17 21:03:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 21:03:38 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <TU9InfBUnO-7lvJWx3C6q8bGUehktFsw5RZjDbr6HTY=.5e0ca81c-358a-481a-90b6-1fe6116dbc33@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
 <TU9InfBUnO-7lvJWx3C6q8bGUehktFsw5RZjDbr6HTY=.5e0ca81c-358a-481a-90b6-1fe6116dbc33@github.com>
Message-ID: <4sUA74yo_nL_YFjlzfBQDf7OPJwBR3em8Il_kkdKhZU=.9ad71dbe-8efb-4b25-ba96-4b93f0caab55@github.com>

On Fri, 17 Jan 2025 20:07:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> It is a good improvement of test stability. However, I am not sure that it fixed test problem.

Me neither. This is impossible to reproduce, so at least a lack of synchronization has to be fixed and then see how it goes.
But thank you for the comment!

> Can the test fails because clock on the host were changed? There are some similar test failures happened when host update clock time during test execution.

Yes, it can. But we can't say for sure.

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

PR Comment: https://git.openjdk.org/jdk/pull/23144#issuecomment-2599199305

From cjplummer at openjdk.org  Fri Jan 17 21:17:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 Jan 2025 21:17:35 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
Message-ID: <tWJa-7jxsjZPI29i0sJ-b5Z7F0fqGBLAdFbpaF8GSAk=.f5df7701-b7db-4970-8e7a-14e89695e98b@github.com>

On Fri, 17 Jan 2025 02:09:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test lacks a synchronization, so it is added by this fix.
>> 
>> Testing:
>>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>>  - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a clarifying comment to monitor declaration

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23144#pullrequestreview-2559995006

From cjplummer at openjdk.org  Fri Jan 17 21:18:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 Jan 2025 21:18:12 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes
Message-ID: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>

When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.

Testing:

- [x] Tier1 CI
- [x] Tier2 CI svc testing
- [x] Tier3 CI svc testing
- [x] Tier5 CI svc testing
- [x] ran all svc test 10 times each on all supported platforms

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

Commit messages:
 - fix jcheck error
 - Use new ClearAllFramePops API to allow compilation after single stepping completes.

Changes: https://git.openjdk.org/jdk/pull/23182/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23182&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8229012
  Stats: 300 lines in 2 files changed: 298 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23182.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23182/head:pull/23182

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

From rriggs at openjdk.org  Fri Jan 17 22:46:35 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Jan 2025 22:46:35 GMT
Subject: RFR: 8347985: Deprecate java.management Permission classes for
 removal
In-Reply-To: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
References: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
Message-ID: <HMiM65x0EA8NqpNW8aX1zBmvTb6W0oakjHOyx08vTnk=.03551a3d-c8bb-43ae-ac18-0896aebe0cf9@github.com>

On Fri, 17 Jan 2025 17:27:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.  This change is for those in the java.management module.

lgtm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23178#pullrequestreview-2560105233

From sspitsyn at openjdk.org  Fri Jan 17 22:48:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Jan 2025 22:48:34 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
Message-ID: <GTGVj6_C1a-P109c_DCxNgq1oM4k21wFAT4gpmWIIiQ=.f92ab520-8110-4723-960b-5c82c5c59c8c@github.com>

On Fri, 17 Jan 2025 02:09:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The test lacks a synchronization, so it is added by this fix.
>> 
>> Testing:
>>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>>  - TBD: submit mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: add a clarifying comment to monitor declaration

Thank you for review, Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/23144#issuecomment-2599332413

From wkemper at openjdk.org  Fri Jan 17 23:22:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Jan 2025 23:22:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
Message-ID: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>

This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

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

Commit messages:
 - Fix whitespace
 - Do not let heap inspection/dump run GC on VM thread

Changes: https://git.openjdk.org/jdk/pull/23186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345750
  Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23186/head:pull/23186

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

From kdnilsen at openjdk.org  Fri Jan 17 23:47:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jan 2025 23:47:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <SnfMsHvY_xs0wrr4eOBK_gEhj-Pu5ZXxzhsvnU_8F0I=.bbc037cc-dd23-4f07-b985-a52c12717aca@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Thanks for handling this.

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

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560162856

From sspitsyn at openjdk.org  Sat Jan 18 00:31:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Jan 2025 00:31:38 GMT
Subject: Integrated: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed
In-Reply-To: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
Message-ID: <LHJQyM7pYu-_rBzlx6BvFg2Axyl9ErLlZYvK5m9-2eU=.c4294982-84b6-426f-a3bc-a566f9130da3@github.com>

On Thu, 16 Jan 2025 09:15:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The test lacks a synchronization, so it is added by this fix.
> 
> Testing:
>  - Ran the failing test `vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002`
>  - TBD: submit mach5 tiers 1-5

This pull request has now been integrated.

Changeset: 6ef860c7
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ef860c728d3f2f29fe8f7318c0f56032e0679be
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8332857: Test vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java failed

Reviewed-by: lmesnik, cjplummer, amenkov

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

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

From ysr at openjdk.org  Sat Jan 18 01:55:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:55:35 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <lgntdS6_JTPWVv8wie7b9mt5QiWgv8X3_WT9fust2C4=.992dc3e8-c9e6-47b4-a251-185a5491cc01@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

LGTM ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23186#pullrequestreview-2560240341

From ysr at openjdk.org  Sat Jan 18 01:59:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 18 Jan 2025 01:59:44 GMT
Subject: RFR: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <_6iRDLUcANVcjyQJOF-M9G8boXICY8mSiQRkl8efsDA=.5dc4916f-0707-44b4-a384-af946bea8518@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.

Please add a suitable testing section/description to the PR (perhaps inducing the conditions that might cause the original issue to manifest without the fix).

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

PR Comment: https://git.openjdk.org/jdk/pull/23186#issuecomment-2599466706

From stuefe at openjdk.org  Sat Jan 18 17:24:45 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 18 Jan 2025 17:24:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v17]
In-Reply-To: <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Clsxfh-4Byhbn_W-sq8Sa5yf7JFnMJ03mPLWtDAWkVs=.3c455f87-e5dd-4c1a-aee5-58f992b1e058@github.com>
Message-ID: <DE_dlnYg5sHRSSeCoKcN5x0xOQFS2rFa87ojXIRy5Ec=.37fb5783-d1e0-4bc7-92ce-f4a11bc7a0b1@github.com>

On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert back to using a flag.

Okay, SAP gave green light too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2599796001

From duke at openjdk.org  Sat Jan 18 17:24:46 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Sat, 18 Jan 2025 17:24:46 GMT
Subject: Integrated: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <SJkQD6WvQnKbOH11ETqQCFzlLw6VDf5F2XjlFChXxe0=.726e2342-1a29-4fe6-bdb6-81c0b22ef441@github.com>

On Fri, 13 Dec 2024 21:29:53 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

This pull request has now been integrated.

Changeset: 3804082c
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3804082cba56e6d26c500880cc5cbe6d4332d8f8
Stats:     124 lines in 19 files changed: 75 ins; 28 del; 21 mod

8346123: [REDO] NMT should not use ThreadCritical

Reviewed-by: dholmes, coleenp, stuefe

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

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

From dholmes at openjdk.org  Mon Jan 20 02:04:45 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jan 2025 02:04:45 GMT
Subject: RFR: 8332857: Test
 vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime002/TestDescription.java
 failed [v2]
In-Reply-To: <4sUA74yo_nL_YFjlzfBQDf7OPJwBR3em8Il_kkdKhZU=.9ad71dbe-8efb-4b25-ba96-4b93f0caab55@github.com>
References: <Otx4tJMZXhsXtvzn37GdR8vkuBQpqJBBQBHTAwmeu6I=.df4dcc90-284d-4e8a-b3cb-11e7c091ba75@github.com>
 <Cv1XAVsRIY_Fx7ZeHWBsitgBj1dixGR7Tv_EfyG-G9o=.8cb5aeda-8cfd-420b-87c8-53f69f2751d9@github.com>
 <TU9InfBUnO-7lvJWx3C6q8bGUehktFsw5RZjDbr6HTY=.5e0ca81c-358a-481a-90b6-1fe6116dbc33@github.com>
 <4sUA74yo_nL_YFjlzfBQDf7OPJwBR3em8Il_kkdKhZU=.9ad71dbe-8efb-4b25-ba96-4b93f0caab55@github.com>
Message-ID: <yD5tC0EB4rLw72Ao3U-uIQNAKgyu3fPdmHviX6yV3JY=.643403ad-d171-4f0a-8066-0e206754ffff@github.com>

On Fri, 17 Jan 2025 21:00:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Can the test fails because clock on the host were changed? There are some similar test failures happened when host update clock time during test execution.

There should be nothing in the test that interacts with the time-of-day clock on the host.

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

PR Comment: https://git.openjdk.org/jdk/pull/23144#issuecomment-2601173660

From dfuchs at openjdk.org  Mon Jan 20 19:04:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Jan 2025 19:04:34 GMT
Subject: RFR: 8344969: Remove the jmx.mxbean.multiname compatibility
 property [v2]
In-Reply-To: <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
 <ZRM_3GPtxwBWUBVINnj_qBP2dpxYyHgqjPtZ8cCcyVc=.115745bd-1ade-4d93-b38d-5c67851398f2@github.com>
Message-ID: <H4Jpg3nBvK5wSsMmaYOBy1cGqFrC0Wc3ZKHZAzHDm-4=.a4795757-8b0b-4d8c-9e3f-187cad7b3bf2@github.com>

On Thu, 16 Jan 2025 09:31:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update/simplification

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23131#pullrequestreview-2563023322

From dfuchs at openjdk.org  Mon Jan 20 19:11:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Jan 2025 19:11:36 GMT
Subject: RFR: 8345049: Remove the jmx.tabular.data.hash.map compatibility
 property
In-Reply-To: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
References: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
Message-ID: <E1UewCjR6YRQy3owU2c_JwnHDMIHqKV0M0oJ_vJ3m2w=.1e9b9d27-0a14-455f-8243-465a3dc0bc15@github.com>

On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23153#pullrequestreview-2563030566

From dfuchs at openjdk.org  Mon Jan 20 19:19:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Jan 2025 19:19:39 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v2]
In-Reply-To: <NldnZBgZdM_gShMsZWmsvyflaDgMUES2sNFhf9AF8WE=.d9c6b6ab-b8d2-4269-8f38-ca02112a8f30@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <NldnZBgZdM_gShMsZWmsvyflaDgMUES2sNFhf9AF8WE=.d9c6b6ab-b8d2-4269-8f38-ca02112a8f30@github.com>
Message-ID: <ymUuNfp28rI5LIbrXUtHjF7zzLi6hDrab15glMkv84E=.98c892c1-481b-4127-9993-7d95fa032516@github.com>

On Fri, 17 Jan 2025 19:14:13 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is a post-SecurityManager-removal cleanup, following-on from:
>> 
>> 8344394: Remove SecurityManager and related calls from java.management.rmi 
>> 
>> 
>> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
>> Remove wrapping of Exceptions in PrivilegedActionException.
>> 
>> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Remove unnecessary/dup catches
>  - Merge remote-tracking branch 'upstream/master' into 8345079_RMIConnectionImpl_excep
>  - unnecessary catches
>  - (c)
>  - 8345079: Simplify/cleanup Exception handling in RMIConnectionImpl

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1008:

> 1006:                 throw (RuntimeException) e;
> 1007:             } else if (e instanceof RuntimeException) {
> 1008:                 throw (RuntimeException) e;

duplicated? see lines 1005-1006

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23072#discussion_r1922778848

From alexey.ivanov at oracle.com  Mon Jan 20 20:16:27 2025
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 20 Jan 2025 20:16:27 +0000
Subject: Remote debugging should print warning when binding to external
 address
In-Reply-To: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
References: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
Message-ID: <a3729eb3-6753-4b56-9383-9df8f76af7b2@oracle.com>

Hello,

Your bug report exists in JBS: https://bugs.openjdk.org/browse/JDK-8329414

On 2025-01-20 20:07, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
> Side note: I am rather certain I had also reported this on the JDK bug 
> tracker through https://bugreport.java.com quite a while ago (unless I 
> am misremembering this) also referring to the IDEA bug report 
> IDEA-349570 in the description, but it seems the JDK bug report was 
> never created and I never got a response (?). See also my general 
> concerns with the current bug reporting in 
> https://mail.openjdk.org/pipermail/web-discuss/2022-January/000593.html.
-- 
Regards,
Alexey

From kevinw at openjdk.org  Mon Jan 20 20:21:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 Jan 2025 20:21:48 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v3]
In-Reply-To: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
Message-ID: <CBDFsJtfWl-1UI7b07LT5OnlFTuF_KwLrwU3gdzJjLc=.adb79d85-3f7d-4388-9786-03f4c9dbd900@github.com>

> This is a post-SecurityManager-removal cleanup, following-on from:
> 
> 8344394: Remove SecurityManager and related calls from java.management.rmi 
> 
> 
> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
> Remove wrapping of Exceptions in PrivilegedActionException.
> 
> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.

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

  oops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23072/files
  - new: https://git.openjdk.org/jdk/pull/23072/files/0f06f752..a07f6bfe

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

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

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

From kevinw at openjdk.org  Mon Jan 20 20:21:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 20 Jan 2025 20:21:51 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v2]
In-Reply-To: <ymUuNfp28rI5LIbrXUtHjF7zzLi6hDrab15glMkv84E=.98c892c1-481b-4127-9993-7d95fa032516@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <NldnZBgZdM_gShMsZWmsvyflaDgMUES2sNFhf9AF8WE=.d9c6b6ab-b8d2-4269-8f38-ca02112a8f30@github.com>
 <ymUuNfp28rI5LIbrXUtHjF7zzLi6hDrab15glMkv84E=.98c892c1-481b-4127-9993-7d95fa032516@github.com>
Message-ID: <5S0QvA98Ika_v01TjHJGpkyHPJG9hgr3fsbiKIoXu2M=.9d199ee0-9cd5-4b52-b915-9840d10b4772@github.com>

On Mon, 20 Jan 2025 19:12:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Remove unnecessary/dup catches
>>  - Merge remote-tracking branch 'upstream/master' into 8345079_RMIConnectionImpl_excep
>>  - unnecessary catches
>>  - (c)
>>  - 8345079: Simplify/cleanup Exception handling in RMIConnectionImpl
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1008:
> 
>> 1006:                 throw (RuntimeException) e;
>> 1007:             } else if (e instanceof RuntimeException) {
>> 1008:                 throw (RuntimeException) e;
> 
> duplicated? see lines 1005-1006

oops 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23072#discussion_r1922817438

From alexey.ivanov at oracle.com  Mon Jan 20 20:47:58 2025
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 20 Jan 2025 20:47:58 +0000
Subject: Remote debugging should print warning when binding to external
 address
In-Reply-To: <8f178482-b193-441c-96bb-73525f1dc3b4@vodafonemail.de>
References: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
 <a3729eb3-6753-4b56-9383-9df8f76af7b2@oracle.com>
 <8f178482-b193-441c-96bb-73525f1dc3b4@vodafonemail.de>
Message-ID: <0da5c8e2-2905-4b28-8c9b-3cbe712b2fe7@oracle.com>

On 2025-01-20 20:36, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
> Thanks for the information! Though I cannot see the report. Is it 
> still pending review / evaluation or was it made private to hide 
> information? Is it still open or was it resolved as "Won't fix" or 
> similar?

Yes, the bug is marked confidential. I didn't notice it right away.

It is open.

> It seems I wasn't informed that the report had been created; at least 
> I cannot find the confirmation mail for it. Note that I had specified 
> a different private contact e-mail address.

It's because the bug isn't public.

> Note: I am dropping serviceability-dev at openjdk.org from CC now. I had 
> originally included it because I thought it might have been better 
> fitting for this mail, but I didn't get a confirmation mail for the 
> list subscription, so I wasn't sure whether the mail would go through.

This discussion belongs on serviceability-dev at openjdk.org. It's 
discuss at openjdk.org that should be dropped.

> 20.01.2025, 21:16 Aleksei Ivanov:
>> Hello,
>>
>> Your bug report exists in JBS: 
>> https://bugs.openjdk.org/browse/JDK-8329414
>>
>> On 2025-01-20 20:07, 
>> some-java-user-99206970363698485155 at vodafonemail.de wrote:
>>> Side note: I am rather certain I had also reported this on the JDK 
>>> bug tracker through https://bugreport.java.com quite a while ago 
>>> (unless I am misremembering this) also referring to the IDEA bug 
>>> report IDEA-349570 in the description, but it seems the JDK bug 
>>> report was never created and I never got a response (?). See also my 
>>> general concerns with the current bug reporting in 
>>> https://mail.openjdk.org/pipermail/web-discuss/2022-January/000593.html. 
>>>
-- 
Regards,
Alexey

From duke at openjdk.org  Tue Jan 21 04:08:42 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Jan 2025 04:08:42 GMT
Subject: Withdrawn: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case
 non-static fields are passed
In-Reply-To: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com>
References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com>
Message-ID: <benI7VT7FFbwbcZKvAdBBC5nf2T4_pmeTgvxof79Lsk=.aac2436d-6660-4f71-9e41-13adbc3ffb78@github.com>

On Wed, 20 Nov 2024 18:09:08 GMT, Adam Bruce <duke at openjdk.org> wrote:

> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. 
> 
> Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead.
> 
> This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process.
> 
> Cheers,
> Adam

This pull request has been closed without being integrated.

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

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

From alan.bateman at oracle.com  Tue Jan 21 08:46:21 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 21 Jan 2025 08:46:21 +0000
Subject: Remote debugging should print warning when binding to external
 address
In-Reply-To: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
References: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
Message-ID: <8b533365-0ffd-4032-9a57-515e2d26caa9@oracle.com>

On 20/01/2025 20:07, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
> :
>
> Therefore I think it would be good if the JDWP connector, when `*` 
> (and maybe `0.0.0.0`) is used, printed a big warning on console which 
> cannot be overlooked, telling the user that this might be insecure.
>

Previously exploration into introducing a warning didn't work out the 
details with some of the JDWP options. Please follow-up on 
serviceability-dev, not the discuss mailing list as that is using for 
discussing about the OpenJDK community.

-Alan

From duke at openjdk.org  Tue Jan 21 09:53:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Jan 2025 09:53:47 GMT
Subject: Withdrawn: 8337199: Add jcmd Thread.vthread_summary diagnostic command
In-Reply-To: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
References: <OZJen5GKkXSW4Blf0vN3WQLTd087jsVb1cCE8MNGAFU=.69395f86-1a1b-4ee7-9b0b-3464b3bd323d@github.com>
Message-ID: <KxCUVhXjWHvVeePHqWr6R6j8QBluZlu59xbiTezDO2o=.51c660cb-2bfd-4088-9100-41e99a1ab5c3@github.com>

On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable <duke at openjdk.org> wrote:

> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
> 
> Summary
> -------
> 
> Add `jcmd <pid> Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads.
> 
> 
> Problem
> -------
> 
> The JDK is lacking tooling to diagnose issues with virtual threads.
> 
> 
> Solution
> --------
> 
> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings.
> 
> Here is sample output. The output is intended for experts and is not intended for automated parsing.
> 
> 
> Virtual thread scheduler:
> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0]
> 
> Timeout schedulers:
> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0]
> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]
> 
> Read I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1]
> 
> Write I/O pollers:
> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0]
> 
> Thread groupings:
> <root> [platform threads = 11, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0]
> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0]
> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0]
> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2]
> ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0]
> java.util.concurrent.Scheduled...

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Tue Jan 21 13:30:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 21 Jan 2025 13:30:07 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails
 with Unable to deduce type of thread from address
Message-ID: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>

We were running into this error :
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25

stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
... 11 more

In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

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

Commit messages:
 - JDK-8347779

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

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

From stooke at openjdk.org  Tue Jan 21 14:25:10 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 21 Jan 2025 14:25:10 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
Message-ID: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>

This fix widens the regex used to determine if a JAVAHEAP line is correct in the output of System.map/System.dump_map.

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

Commit messages:
 - widen JAVAHEAP regex again

Changes: https://git.openjdk.org/jdk/pull/23205/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346927
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23205.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23205/head:pull/23205

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

From kevinw at openjdk.org  Tue Jan 21 14:25:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Jan 2025 14:25:10 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
Message-ID: <2y4JFIyVmqp9_h6m0EpYsiRp4bVIUcCV6D6yizCFjEc=.a00e6478-354b-4793-b403-d7c949b40a0b@github.com>

On Mon, 20 Jan 2025 21:25:51 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This fix widens the regex used to determine if a JAVAHEAP line is correct in the output of System.map/System.dump_map.

Looks good 8-)

Hi,
>From our logs - existing passes on macos aarch64 include a line which matches, e.g.:

0x0007c8000000-0x0007d0000000            134217728 rw-/rwx pvt            0  JAVAHEAP 

The failures where we don't match, they have p/a rather than pvt:

0x00030e900000-0x00030ec00000 3145728     rw-/rwx p/a 0 JAVAHEAP

There are also the  "cow" lines, I see in the JAVAHEAP classes.jsa line.

I think we don't specifically need "cow" in the macprivate_or_shared definition - as long as we match the JAVAHEAP line with p/a we will pass.  It's only classes.jsa marked a copy on write (makes sense), and there should always be another JAVAHEAP line for us to match.

Presuming "private aliased" is a variation of private, so adding p/a variant is a trivial change for the test.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23205#pullrequestreview-2564777308
PR Comment: https://git.openjdk.org/jdk/pull/23205#issuecomment-2604319139

From stooke at openjdk.org  Tue Jan 21 14:25:11 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 21 Jan 2025 14:25:11 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <2y4JFIyVmqp9_h6m0EpYsiRp4bVIUcCV6D6yizCFjEc=.a00e6478-354b-4793-b403-d7c949b40a0b@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
 <2y4JFIyVmqp9_h6m0EpYsiRp4bVIUcCV6D6yizCFjEc=.a00e6478-354b-4793-b403-d7c949b40a0b@github.com>
Message-ID: <fDfwnuq6nTy6xQ-jiM9AZCZt5tv98GixWBeYsi6lFPs=.eafaa4b4-0217-461c-b0cc-e9fe31a4ff11@github.com>

On Tue, 21 Jan 2025 10:26:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This fix widens the regex used to determine if a JAVAHEAP line is correct in the output of System.map/System.dump_map.
>
> Hi,
> From our logs - existing passes on macos aarch64 include a line which matches, e.g.:
> 
> 0x0007c8000000-0x0007d0000000            134217728 rw-/rwx pvt            0  JAVAHEAP 
> 
> The failures where we don't match, they have p/a rather than pvt:
> 
> 0x00030e900000-0x00030ec00000 3145728     rw-/rwx p/a 0 JAVAHEAP
> 
> There are also the  "cow" lines, I see in the JAVAHEAP classes.jsa line.
> 
> I think we don't specifically need "cow" in the macprivate_or_shared definition - as long as we match the JAVAHEAP line with p/a we will pass.  It's only classes.jsa marked a copy on write (makes sense), and there should always be another JAVAHEAP line for us to match.
> 
> Presuming "private aliased" is a variation of private, so adding p/a variant is a trivial change for the test.

@kevinjwalls thanks for the suggestion.  I wish I could duplicate your issue.
I prefer to leave 'cow' in, as the goal of this test is to ensure System.map works, not to confirm the implementation of a specific garbage collector.  That was the consensus reached when ZGC caused the first failure on macOS.

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

PR Comment: https://git.openjdk.org/jdk/pull/23205#issuecomment-2604721965

From stooke at openjdk.org  Tue Jan 21 14:25:11 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 21 Jan 2025 14:25:11 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <peDEWbIUp3baWFooQ58cIRBvT6rt8Dx_2UKRjdP_Ctc=.102a6395-12e4-4042-b813-74e61f0e2d45@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
 <2y4JFIyVmqp9_h6m0EpYsiRp4bVIUcCV6D6yizCFjEc=.a00e6478-354b-4793-b403-d7c949b40a0b@github.com>
 <fDfwnuq6nTy6xQ-jiM9AZCZt5tv98GixWBeYsi6lFPs=.eafaa4b4-0217-461c-b0cc-e9fe31a4ff11@github.com>
 <peDEWbIUp3baWFooQ58cIRBvT6rt8Dx_2UKRjdP_Ctc=.102a6395-12e4-4042-b813-74e61f0e2d45@github.com>
Message-ID: <jxdSeWacGH4BkhBiSGu196B03qqYqOHVPqNLlRELy-8=.d1b9b4e2-975d-4f46-a5ef-64c195b5cb17@github.com>

On Tue, 21 Jan 2025 13:50:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> @kevinjwalls thanks for the suggestion.  I wish I could duplicate your issue.
>> I prefer to leave 'cow' in, as the goal of this test is to ensure System.map works, not to confirm the implementation of a specific garbage collector.  That was the consensus reached when ZGC caused the first failure on macOS.
>
>> ....prefer to leave 'cow' in, as the goal of this test is to ensure System.map works, not to confirm the implementation of a specific garbage collector. That was the consensus reached when ZGC caused the first failure on macOS.
> 
> Sure, it doesn't matter hugely.  Presumably you intended to sanity-check the output in reasonable detail, and that gives us the test we have.    I don't see any output so far where the cow lines for classes.jsa will happen, I think the "p/a JAVAHEAP" lines will match and the test will remove that regex, meaning success.  But leaving it in is not a problem for me.

@kevinjwalls thanks for looking at this - I'll submit it now.

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

PR Comment: https://git.openjdk.org/jdk/pull/23205#issuecomment-2604853645

From kevinw at openjdk.org  Tue Jan 21 14:25:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Jan 2025 14:25:11 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <fDfwnuq6nTy6xQ-jiM9AZCZt5tv98GixWBeYsi6lFPs=.eafaa4b4-0217-461c-b0cc-e9fe31a4ff11@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
 <2y4JFIyVmqp9_h6m0EpYsiRp4bVIUcCV6D6yizCFjEc=.a00e6478-354b-4793-b403-d7c949b40a0b@github.com>
 <fDfwnuq6nTy6xQ-jiM9AZCZt5tv98GixWBeYsi6lFPs=.eafaa4b4-0217-461c-b0cc-e9fe31a4ff11@github.com>
Message-ID: <peDEWbIUp3baWFooQ58cIRBvT6rt8Dx_2UKRjdP_Ctc=.102a6395-12e4-4042-b813-74e61f0e2d45@github.com>

On Tue, 21 Jan 2025 13:21:43 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> ....prefer to leave 'cow' in, as the goal of this test is to ensure System.map works, not to confirm the implementation of a specific garbage collector. That was the consensus reached when ZGC caused the first failure on macOS.

Sure, it doesn't matter hugely.  Presumably you intended to sanity-check the output in reasonable detail, and that gives us the test we have.    I don't see any output so far where the cow lines for classes.jsa will happen, I think the "p/a JAVAHEAP" lines will match and the test will remove that regex, meaning success.  But leaving it in is not a problem for me.

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

PR Comment: https://git.openjdk.org/jdk/pull/23205#issuecomment-2604792611

From duke at openjdk.org  Tue Jan 21 14:25:11 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Jan 2025 14:25:11 GMT
Subject: RFR: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
Message-ID: <76RO9r75A0dCOJVUERJYRjkG8Ql5raxo2ZeCwIZBUgQ=.799b97a6-39e4-4cf7-bbfa-321f0520c112@github.com>

On Mon, 20 Jan 2025 21:25:51 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This fix widens the regex used to determine if a JAVAHEAP line is correct in the output of System.map/System.dump_map.

@stooke 
Your change (at version 238e9c0b45f7210168dd9a10f661a00b26c5da70) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23205#issuecomment-2604871886

From dfuchs at openjdk.org  Tue Jan 21 14:32:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jan 2025 14:32:40 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
In-Reply-To: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
Message-ID: <5efPW0TPw60MzKNllRu_Z-dNvaUsipgh6PcW6VmbFk0=.6d82435e-1ca6-4045-9d1b-f119420c7eaa@github.com>

On Wed, 15 Jan 2025 12:15:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
> 
> It should be removed.

LGTM.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23132#pullrequestreview-2564809148

From dfuchs at openjdk.org  Tue Jan 21 14:43:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 21 Jan 2025 14:43:39 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v3]
In-Reply-To: <CBDFsJtfWl-1UI7b07LT5OnlFTuF_KwLrwU3gdzJjLc=.adb79d85-3f7d-4388-9786-03f4c9dbd900@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <CBDFsJtfWl-1UI7b07LT5OnlFTuF_KwLrwU3gdzJjLc=.adb79d85-3f7d-4388-9786-03f4c9dbd900@github.com>
Message-ID: <N573oQiO1HgIlpCPuj-3Wtkf4kvG6EDxy0_-KfqLBJM=.da2a5fdf-a39b-40c0-b05d-c946e1c7ea3d@github.com>

On Mon, 20 Jan 2025 20:21:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is a post-SecurityManager-removal cleanup, following-on from:
>> 
>> 8344394: Remove SecurityManager and related calls from java.management.rmi 
>> 
>> 
>> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
>> Remove wrapping of Exceptions in PrivilegedActionException.
>> 
>> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oops

Look good. As a matter of style you could further simplify to:


} catch (XException | YException | ZException ex) {
    throw ex;
} catch (Exception unexpected) {
     throw new IOException("Got unexpected server exception: " + unexpected, unexpected);
}


but that doesn't need to be in this changeset. Also it would be harder to review ;-)

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23072#pullrequestreview-2564842103

From kevinw at openjdk.org  Tue Jan 21 14:53:40 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Jan 2025 14:53:40 GMT
Subject: RFR: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl [v3]
In-Reply-To: <CBDFsJtfWl-1UI7b07LT5OnlFTuF_KwLrwU3gdzJjLc=.adb79d85-3f7d-4388-9786-03f4c9dbd900@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
 <CBDFsJtfWl-1UI7b07LT5OnlFTuF_KwLrwU3gdzJjLc=.adb79d85-3f7d-4388-9786-03f4c9dbd900@github.com>
Message-ID: <fzxBKcK94rH3_wiVzRVe-nk6OrdzmxIrBDe-xNprgkU=.02b1eeed-c639-4af5-936a-df089d03f8ae@github.com>

On Mon, 20 Jan 2025 20:21:48 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This is a post-SecurityManager-removal cleanup, following-on from:
>> 
>> 8344394: Remove SecurityManager and related calls from java.management.rmi 
>> 
>> 
>> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
>> Remove wrapping of Exceptions in PrivilegedActionException.
>> 
>> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   oops

Thanks Daniel.  Yes, we could do quite a big style update here in future!

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

PR Comment: https://git.openjdk.org/jdk/pull/23072#issuecomment-2604945705

From some-java-user-99206970363698485155 at vodafonemail.de  Mon Jan 20 20:07:41 2025
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Mon, 20 Jan 2025 21:07:41 +0100
Subject: Remote debugging should print warning when binding to external address
Message-ID: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>

Hello,

in JDK 9 the behavior of the JDWP socket connector was changed to only 
allow local connections by default [1]. This was likely done for two 
reasons:

 1. In earlier versions JDWP would also listen for external connections
    by default
 2. When JDWP is exposed externally it represents a big security risk
    because it allows remote code execution

Especially the second point might not be obvious to average users, but 
it is well known to security researchers and malicious actors.

The problem is that besides this JDK 9 release note which probably 
nowadays no one is going to read anymore, these security implications 
seem to be nowhere properly and well visible documented. So what 
happened is that multiple forums, blogs and IDEs (e.g. 
https://youtrack.jetbrains.com/issue/IDEA-349570) started suggesting 
using `*` (= bind to all interfaces) without mentioning the security 
implications prominently, or at all. This completely defeats why this 
change in the JDK was done in the first place.

Therefore I think it would be good if the JDWP connector, when `*` (and 
maybe `0.0.0.0`) is used, printed a big warning on console which cannot 
be overlooked, telling the user that this might be insecure.
For example something like this or similar (any suggestions are welcome):

> $ java 
> "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=*:5005" 
> DebugTest.java
> Listening for transport dt_socket at address: 5005
> ******** SECURITY WARNING ********
> Listening on all network interfaces for debug connections 
> (`address=*:<port>`) is insecure and can lead to remote code execution 
> if the machine is reachable from the internet and no firewall prevents 
> the connection.
> Prefer listening only for local connections (`address=<port>`), and if 
> remote access is necessary use tools such as SSH to secure the connection.
> **********************************
It might also be good to create a page for example on https://dev.java/ 
and link to it in this console message, which explains how SSH can be 
used for this and which contains more information.

The alternative is spending a lifetime chasing down blogs and comments 
which recommend using `*` and telling them to stop doing this or at 
least to mention the security implications.

Additionally maybe the documentation should mention the security 
implications of JDWP, though I am not sure if there is one canonical 
page about it. All information on oracle.com seem to be rather technical 
specification documents, the closest might be 
https://docs.oracle.com/en/java/javase/23/docs/specs/jpda/conninv.html
Compare this also with how other tools are handling security 
implications of remote debugging, e.g. Node.js with 
https://nodejs.org/en/learn/getting-started/debugging#security-implications

Kind regards


[1] 
https://www.oracle.com/java/technologies/javase/9-all-relnotes.html#JDK-8041435


Side note: I am rather certain I had also reported this on the JDK bug 
tracker through https://bugreport.java.com quite a while ago (unless I 
am misremembering this) also referring to the IDEA bug report 
IDEA-349570 in the description, but it seems the JDK bug report was 
never created and I never got a response (?). See also my general 
concerns with the current bug reporting in 
https://mail.openjdk.org/pipermail/web-discuss/2022-January/000593.html.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250120/e3a28eb9/attachment-0001.htm>

From stooke at openjdk.org  Tue Jan 21 15:04:56 2025
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 21 Jan 2025 15:04:56 GMT
Subject: Integrated: 8346927:
 serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx
In-Reply-To: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
References: <RHtM2p4ckvLyubjZSdXAIKlo86w5_7153hNRsUY7BfY=.dbb0d3dd-d4d3-40d0-9eb4-a927a3d32f6b@github.com>
Message-ID: <7SRqdljEtnmTbt_9uED5Lncjr7XM4QdrFwyBchM1fN8=.4b29e3ce-aa72-48e3-83ad-2c6a6c116732@github.com>

On Mon, 20 Jan 2025 21:25:51 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This fix widens the regex used to determine if a JAVAHEAP line is correct in the output of System.map/System.dump_map.

This pull request has now been integrated.

Changeset: 1ed396b4
Author:    Simon Tooke <stooke at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ed396b4fc5e8e5ed69694449993b9330e396531
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8346927: serviceability/dcmd/vm/[SystemMapTest.java|SystemDumpMapTest.java] fail at jmx

Reviewed-by: kevinw

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

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

From kevinw at openjdk.org  Tue Jan 21 17:25:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Jan 2025 17:25:48 GMT
Subject: Integrated: 8345079: Simplify/cleanup Exception handling in
 RMIConnectionImpl
In-Reply-To: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
References: <A2yVNWAv3iCKlkG_wCKQuuKP8q68XTI1eiPP3LJD8Hc=.a5a85ca5-b70c-43d3-be91-f2e59e126fb9@github.com>
Message-ID: <NSyXTGNHmTG9RpZJ4QRBuaiILunqu0UjrrIPaykLoTY=.f31f8410-1c61-484a-a619-17eb9b98f6f0@github.com>

On Mon, 13 Jan 2025 13:56:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This is a post-SecurityManager-removal cleanup, following-on from:
> 
> 8344394: Remove SecurityManager and related calls from java.management.rmi 
> 
> 
> Remove mention of "privilege" in Exception handling in RMIConnectionImpl.
> Remove wrapping of Exceptions in PrivilegedActionException.
> 
> The methods that invoke an operation handle expected Exceptions, but also need to handle SecurityException and RuntimeException, to avoid their default case of wrapping an Exception in an IOException to signal a problem.

This pull request has now been integrated.

Changeset: 3d4afc49
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d4afc492ac3054fe2bd10f0a76635a613f31033
Stats:     190 lines in 1 file changed: 49 ins; 60 del; 81 mod

8345079: Simplify/cleanup Exception handling in RMIConnectionImpl

Reviewed-by: dfuchs

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

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

From wkemper at openjdk.org  Tue Jan 21 18:38:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:38:50 GMT
Subject: Integrated: 8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive
 intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
References: <Y2VTZom5-Xi8Kg73VEhiXhHXG3cnl90y7BF3nfMMVzw=.1bb31fba-f10f-4272-ae9e-282c9588fdab@github.com>
Message-ID: <w52MQ3D9h1dDH78nZbCGLtxNRPvyPdqKH8sIkf33L_Q=.d4309bf1-4934-4465-a976-70f904f968fb@github.com>

On Fri, 17 Jan 2025 23:12:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This occurs when an attempt to produce a heap dump conflicts with a concurrent cycle. The heap dump vm operation attempts to run a cycle directly on the VM thread with no regard for the state of the concurrent collection. Although Shenandoah _is_ technically capable of running an entire _full_ GCs on the vm thread, I would rather not add another dependency on full GCs, nor would I like to cancel an in-progress concurrent GC. Instead, Shenandoah will follow the pattern established ZGC in which the calling thread waits for a concurrent cycle to complete before taking the heap dump.
> 
> ## Testing
> 
> Shenandoh's jtreg test: `gc/shenandoah/TestJcmdHeapDump.java` simply takes a heap dump of itself. Before this change I observed a failure rate of approximately 1/6000 executions. The assertion is violated when the VM thread attempts to run a collection which is not coordinated by Shenandoah's control thread. This specific assertion happens because the default implementation of `collect_as_vm_thread` modifies the `_gc_cause` field in ways that Shenandoah does not expect. Without this assertion, one can only imagine the chaos that would ensue.

This pull request has now been integrated.

Changeset: 6a29a811
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a29a8110ec38b4adc8163ba8651cbc935353f1d
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Tue Jan 21 18:52:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 18:52:48 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
Message-ID: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>

This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

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

Commit messages:
 - Backport 6a29a8110ec38b4adc8163ba8651cbc935353f1d

Changes: https://git.openjdk.org/jdk/pull/23221/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345750
  Stats: 23 lines in 4 files changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/23221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23221/head:pull/23221

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

From cjplummer at openjdk.org  Tue Jan 21 19:11:42 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 Jan 2025 19:11:42 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address
In-Reply-To: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
Message-ID: <OrqWvj8TS0YFzocix6PG0RU5bvVeWgrblsIG1oi5PHI=.37c7d675-a04d-40a9-8f18-9c6ab70390a0@github.com>

On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
> 
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
> 
> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 84:

> 82:             output.shouldHaveExitValue(0);
> 83:         } catch (Exception ex) {
> 84:             if (allowRetry) return false;

The exception should be printed if we are going to retry, and also maybe print a message that mentions retrying similar to what we do in printStackTraces()L

122                     System.out.println("'JShellToolProvider' missing. Allow one retry.");

test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104:

> 102:         if (!res) { // try once more
> 103:             launch(expectedMessage, Arrays.asList(toolArgs), false);
> 104:         }

`launch()` should take an allowRetry argument and only retry if true. This test is operated in two different modes. One is with an active target process and one is with a target process that should be stabilized and inactive. The latter is not allowed to retry since it should never fail. Also, it would help to add a comment as to why the retry is being done. See the comment in `printStackTrace()`.

I think a better approach would be for launch() to just return if a retry should be done. testHeapDump() should check the result, and just immediately return true if launch() returns true.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924239855
PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924237704

From prr at openjdk.org  Tue Jan 21 19:44:42 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Jan 2025 19:44:42 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules
In-Reply-To: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
Message-ID: <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>

On Wed, 8 Jan 2025 20:13:50 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
> 
> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
> 
> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
> 
> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288:

> 1286: 
> 1287:     /**
> 1288:      * Serializes this {@code DataFlavor}.

This most definitely changes the serialisation spec. So a CSR is needed.
Also shouldn't readExternal be updated to correspond ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924275958

From some-java-user-99206970363698485155 at vodafonemail.de  Tue Jan 21 20:57:27 2025
From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de)
Date: Tue, 21 Jan 2025 21:57:27 +0100
Subject: Remote debugging should print warning when binding to external
 address
In-Reply-To: <0da5c8e2-2905-4b28-8c9b-3cbe712b2fe7@oracle.com>
References: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
 <a3729eb3-6753-4b56-9383-9df8f76af7b2@oracle.com>
 <8f178482-b193-441c-96bb-73525f1dc3b4@vodafonemail.de>
 <0da5c8e2-2905-4b28-8c9b-3cbe712b2fe7@oracle.com>
Message-ID: <5482a0ac-f56b-4115-8a53-1ea1cdaf8211@vodafonemail.de>

>> It seems I wasn't informed that the report had been created; at least 
>> I cannot find the confirmation mail for it. Note that I had specified 
>> a different private contact e-mail address.
>
> It's because the bug isn't public. 
... but I am the reporter!? It could of course be that there was an 
attempt to inform me but it did not reach me for whatever reason (please 
don't mention the e-mail address, I used for reporting, here on this 
mailing list though).

That is unfortunately exactly what I had been criticizing in 
https://mail.openjdk.org/pipermail/web-discuss/2022-January/000593.html; 
as external reporter it can be extremely intransparent what happens to a 
report.

> Yes, the bug is marked confidential.
I don't really understand that. Unless I accidentally leaked private 
information in the report, I think it contains exactly the information I 
wrote in the original e-mail of this thread. And this is not secret 
information, it is basically what had been mentioned in the JDK 9 
release notes originally. It is rather weird to withhold this 
information from users, especially since malicious actors are long aware 
of the security issues see for example 
https://www.alibabacloud.com/blog/analysis-of-jdwpminer-mining-trojan-remote-debugging-with-java-causes-hidden-risks_598002 
or just search for "jdwp exploit" or similar.

(Aleksei Ivanov I have included you as direct recipient of this mail; 
but this mail might still be awaiting approval on serviceability-dev@, 
so in case you respond before that it might be confusing for others.)


From ysr at openjdk.org  Tue Jan 21 22:45:37 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 21 Jan 2025 22:45:37 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <G4TSKokMyIFKnDnZlYitEgSNHtuRhoZfynStRztcDIk=.dbe42d6a-0b0d-4ae3-b267-9ca3c8d1a53b@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23221#pullrequestreview-2565838091

From wkemper at openjdk.org  Tue Jan 21 23:12:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 21 Jan 2025 23:12:40 GMT
Subject: [jdk24] Integrated: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <TGmKVQYKJrZ4FVBdpfAWh0MXoKYvucAKm3jYRSqZUXs=.4d77266b-d2a3-4254-94b0-5e3cfdee9439@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

This pull request has now been integrated.

Changeset: febcfd69
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/febcfd69ffe88e8a9d3cdf267bc062816577f868
Stats:     23 lines in 4 files changed: 15 ins; 1 del; 7 mod

8345750: Shenandoah: Test TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() == GCCause::_no_gc) failed: Over-writing cause

Reviewed-by: ysr
Backport-of: 6a29a8110ec38b4adc8163ba8651cbc935353f1d

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

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

From dholmes at openjdk.org  Wed Jan 22 05:25:34 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 05:25:34 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <K6At2J1BtJH2LXNQMRvntT_apJaOHYXhoGgIBqUaOiQ=.d9120764-6729-45b8-8841-174edb9a64d0@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Looks fine. Thanks for cleaning it up.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23222#pullrequestreview-2566215728

From sspitsyn at openjdk.org  Wed Jan 22 07:51:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Jan 2025 07:51:46 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes
In-Reply-To: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
Message-ID: <tRFYkqpJ3E8pcw2u_t70dHJUTgwbQLwpX86dxQDpEjo=.2521f030-27bf-4401-846c-df56e0993409@github.com>

On Fri, 17 Jan 2025 20:31:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
> 
> Testing:
> 
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on all supported platforms

The fix looks good in general but posted some minor comments.

It is nice the update is reasonably simple. :)

src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 940:

> 938: 
> 939:         if (needsSuspending) {
> 940:             tty_message("clearStep: resuming thread");

Q: Lines: 913, 940. Should such a message printing be under the `#ifdef DEBUG` ?

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 30:

> 28:  * @bug 8229012
> 29:  * @summary Verify that during single stepping a method is not compiled and
> 30:  *          after single stepping it is compiled..

Nit: The dots are not needed at the end.

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 32:

> 30:  *          after single stepping it is compiled..
> 31:  * @requires vm.compMode == "Xmixed"
> 32:  * @library /test/lib /

Q: Just want to make sure the`/` at the end is not a typo. :)

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 228:

> 226:         /*
> 227:          * Deal with results of test. If anything has called failure("foo")
> 228:          * then testFailed will be true

Nit: Need dots at the end of lines: 200, 207 and 228.

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

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2566380444
PR Comment: https://git.openjdk.org/jdk/pull/23182#issuecomment-2606515615
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1924818178
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1924820257
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1924821505
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1924839521

From mbaesken at openjdk.org  Wed Jan 22 08:52:37 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 Jan 2025 08:52:37 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address
In-Reply-To: <OrqWvj8TS0YFzocix6PG0RU5bvVeWgrblsIG1oi5PHI=.37c7d675-a04d-40a9-8f18-9c6ab70390a0@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <OrqWvj8TS0YFzocix6PG0RU5bvVeWgrblsIG1oi5PHI=.37c7d675-a04d-40a9-8f18-9c6ab70390a0@github.com>
Message-ID: <nAo5BNCnt66BjtooqVLCBSjfFtFk2dt776BVERnClb4=.6f228865-7346-4e63-a880-e8e4ebcd492e@github.com>

On Tue, 21 Jan 2025 19:06:40 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> launch() should take an allowRetry argument and only retry if true.

Are you talking about `public static void launch(String expectedMessage, String... toolArgs)`   ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924930551

From mbaesken at openjdk.org  Wed Jan 22 09:15:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 22 Jan 2025 09:15:10 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v2]
In-Reply-To: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
Message-ID: <2RmUz6EFb4bFPahDd48JpIlonqxmje6PXB_dtWTRCcw=.d272af05-135d-4cfe-a76c-c2794ec4d416@github.com>

> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
> 
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
> 
> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  More output in case of retry in launch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23213/files
  - new: https://git.openjdk.org/jdk/pull/23213/files/9e638a3e..b54de9b1

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

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

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

From hannesw at openjdk.org  Wed Jan 22 09:25:43 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 22 Jan 2025 09:25:43 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules
In-Reply-To: <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>
Message-ID: <SHu8usWkPnJ3tmmiTXpqkqaquCeF_XjKuwHhH2psSRw=.72d2f6bb-f887-4775-b3d5-b2be3755ac00@github.com>

On Tue, 21 Jan 2025 19:41:39 GMT, Phil Race <prr at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288:
> 
>> 1286: 
>> 1287:     /**
>> 1288:      * Serializes this {@code DataFlavor}.
> 
> This most definitely changes the serialisation spec. So a CSR is needed.
> Also shouldn't readExternal be updated to correspond ?

Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that.

@prrace do you have any suggestions for the spec change, or are you ok with the proposed wording?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1924979277

From shade at openjdk.org  Wed Jan 22 09:31:36 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jan 2025 09:31:36 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <K718EqA2vrV3XUH5mJ5d8QNNzAUiBnvkxffIl1tU-SQ=.06beb7ca-bca1-4824-a547-2bbe8b2585b4@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23222#pullrequestreview-2566657064

From kevinw at openjdk.org  Wed Jan 22 10:17:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 22 Jan 2025 10:17:11 GMT
Subject: RFR: 8348265: RMIConnectionImpl: Remove Subject.callAs on
 MarshalledObject
Message-ID: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>

Redundant after Security Manager removal, remove the Subject.callAs() call on a MashalledObject.cast().
Previously, a Policy could possibly have restricted permissable classes available to the cast().

Nothing in our tests fails if we remove the callAs.

Also fixing a comment typo ("reqIncomming") and rewording that comment.

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

Commit messages:
 - 8348265: RMIConnectionImpl: Remove Subject.callAs on MarshalledObject

Changes: https://git.openjdk.org/jdk/pull/23230/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23230&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348265
  Stats: 15 lines in 1 file changed: 0 ins; 13 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23230.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23230/head:pull/23230

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

From coleenp at openjdk.org  Wed Jan 22 12:24:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 12:24:44 GMT
Subject: RFR: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <idM2o8uKep6LJiNYyVVuzlmhEPGF8XH5MOUkATbUz0Y=.e970c057-17fb-4fd8-a0e5-745f633110a1@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

Thanks for reviewing David and Aleksey.

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

PR Comment: https://git.openjdk.org/jdk/pull/23222#issuecomment-2607102885

From coleenp at openjdk.org  Wed Jan 22 12:24:45 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jan 2025 12:24:45 GMT
Subject: Integrated: 8337458: Remove debugging code print_cpool_bytes
In-Reply-To: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
References: <nnCh8suS0JZ2ls96kZ6kCTOFyMK0qNRkH8RBUsMACcY=.e22fff97-730d-4ac7-b8f4-bbc336cd77b7@github.com>
Message-ID: <7ZHuVIo0XCKk-GE1NITDT5b61sUgcmBPYZO04iFw-F0=.93481fe6-6f4c-47eb-ab58-13e91389b2a0@github.com>

On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to remove debug printing code that was added temporarily for the ClassFileReconstituter to debug constant pool copying a long time ago, that is now unused.
> Tested with tier1 locally.

This pull request has now been integrated.

Changeset: 86a8b48b
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86a8b48b6cc315bae8d385c5c3aafcc6bd401e59
Stats:     153 lines in 1 file changed: 0 ins; 153 del; 0 mod

8337458: Remove debugging code print_cpool_bytes

Reviewed-by: dholmes, shade

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

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

From prr at openjdk.org  Wed Jan 22 20:37:51 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 22 Jan 2025 20:37:51 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules
In-Reply-To: <SHu8usWkPnJ3tmmiTXpqkqaquCeF_XjKuwHhH2psSRw=.72d2f6bb-f887-4775-b3d5-b2be3755ac00@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>
 <SHu8usWkPnJ3tmmiTXpqkqaquCeF_XjKuwHhH2psSRw=.72d2f6bb-f887-4775-b3d5-b2be3755ac00@github.com>
Message-ID: <LEVRzFIWyxMqJO2jn0-6OIP0olEZzb1zgUqqGjMCyZk=.19b783da-c221-46ef-b3ef-9dce7100b9af@github.com>

On Wed, 22 Jan 2025 09:23:10 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java line 1288:
>> 
>>> 1286: 
>>> 1287:     /**
>>> 1288:      * Serializes this {@code DataFlavor}.
>> 
>> This most definitely changes the serialisation spec. So a CSR is needed.
>> Also shouldn't readExternal be updated to correspond ?
>
> Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that.
> 
> @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording?

There's not a great number of "good" examples of this in the JDK, so probably OK except it
seems like most cases will do it like a normal javadoc method so you'd want an @param tag too.

note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1925928563

From dholmes at openjdk.org  Wed Jan 22 21:02:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jan 2025 21:02:00 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <vQSFQilU7ukjazHSDGhoFFkxv5FlTQ2hsuh_cF28zK0=.cff0d302-b74d-40c0-9716-251f62541488@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn and @ysramakrishna  JDK 24 is already in RDP2 and as such this P3 issue should not have been integrated there. Did you really intend to send this to jdk24u?

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

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2608255604

From cjplummer at openjdk.org  Wed Jan 22 21:19:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Jan 2025 21:19:49 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v2]
In-Reply-To: <nAo5BNCnt66BjtooqVLCBSjfFtFk2dt776BVERnClb4=.6f228865-7346-4e63-a880-e8e4ebcd492e@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <OrqWvj8TS0YFzocix6PG0RU5bvVeWgrblsIG1oi5PHI=.37c7d675-a04d-40a9-8f18-9c6ab70390a0@github.com>
 <nAo5BNCnt66BjtooqVLCBSjfFtFk2dt776BVERnClb4=.6f228865-7346-4e63-a880-e8e4ebcd492e@github.com>
Message-ID: <nJ3XKg7ydAC58YpB73oNZs2QqNXTUBB2Ir7KSzPPIwg=.f0997a40-02b2-49da-acc5-47c7e9b9fedd@github.com>

On Wed, 22 Jan 2025 08:49:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104:
>> 
>>> 102:         if (!res) { // try once more
>>> 103:             launch(expectedMessage, Arrays.asList(toolArgs), false);
>>> 104:         }
>> 
>> `launch()` should take an allowRetry argument and only retry if true. This test is operated in two different modes. One is with an active target process and one is with a target process that should be stabilized and inactive. The latter is not allowed to retry since it should never fail. Also, it would help to add a comment as to why the retry is being done. See the comment in `printStackTrace()`.
>> 
>> I think a better approach would be for launch() to just return if a retry should be done. testHeapDump() should check the result, and just immediately return true if launch() returns true.
>
>> launch() should take an allowRetry argument and only retry if true.
> 
> Are you talking about `public static void launch(String expectedMessage, String... toolArgs)`   ?

Yes, but my suggestion on how to fix this might not be the best one. It's a bit hard to get the naming and usage of flags and logic right here. allowRetry, vs retry, vs doSleep. They all relate. Bottom line is that we should only ever attempt a retry if doSleep is false. Right now that flag is checked in printStackTraces(), and determines if true should be returned to allow a retry, but only if we aren't already doing a retry. Something similar needs to be done with launch() when it is deciding to return true or false after a failure. Right now it is only checking the allowRetry flag, but it should also check the doSleep flag.

I think in testHeapDump(), the calling of `launch(String expectedMessage, String... toolArgs)` should be done in a way similar to calling `printStackTraces()`. Pass in allowRetry and assign the result to the retry boolean. If retry is true, then return it right away (back to main() so it can retry). In `launch(String expectedMessage, String... toolArgs)`, only call `launch(String expectedMessage, List<String> toolArgs, boolean allowRetry)` once, passing in allowRetry flag. In `launch(String expectedMessage, List<String> toolArgs, boolean allowRetry)`, only return true to allow a retry if allowRetry is true and doSleep is false.

Anyway, it's kind of messy and there may be another way. The key issue with your current version is that it always allows for a retry, but it should only allow a retry if doSleep is false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1925979789

From mbaesken at openjdk.org  Thu Jan 23 09:07:23 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 Jan 2025 09:07:23 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v3]
In-Reply-To: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
Message-ID: <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>

> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
> 
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
> 
> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  check doSleep in launch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23213/files
  - new: https://git.openjdk.org/jdk/pull/23213/files/b54de9b1..168f6561

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

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

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

From kevinw at openjdk.org  Thu Jan 23 09:25:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 09:25:47 GMT
Subject: RFR: 8345049: Remove the jmx.tabular.data.hash.map compatibility
 property
In-Reply-To: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
References: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
Message-ID: <rjJVjn3_y-LCvRkdPaWRv9JXt1Mxc17RIbbXUiKqvRU=.73ac6aa2-da23-4c9e-87fd-a0bacd45f884@github.com>

On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

Thanks for the reviews, on all these old-property-removal changes!

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

PR Comment: https://git.openjdk.org/jdk/pull/23153#issuecomment-2609288784

From kevinw at openjdk.org  Thu Jan 23 09:31:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 09:31:51 GMT
Subject: Integrated: 8344966: Remove the allowNonPublic MBean compatibility
 property
In-Reply-To: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
References: <g6gs1WyBDcH0w7xi4h8F9_7PF6Syl8Dxo6wVXMYs-1U=.96d483eb-3858-456b-8aa1-3976d632d2a7@github.com>
Message-ID: <oaNyQll4O79RSO-tsnSWRBRPXGsPi8At6SAdBwVlRsI=.4c2de38c-034c-477a-a683-ffe604668f84@github.com>

On Tue, 14 Jan 2025 09:39:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jdk.jmx.mbeans.allowNonPublic" was added with JDK-8010285, to optionally be compatible with a time before JDK-8, when Management Interfaces being public was not enforced.
> 
> From JDK-8010285:
> _The system property "jdk.jmx.mbeans.allowNonPublic" is used to revert to the old behaviour allowing non-public management interfaces. This property is considered to be transitional and will be removed in the subsequent releases._
> 
> 
> 
> That was a long time ago.  This compatibility convenience flag should be removed.

This pull request has now been integrated.

Changeset: c882160d
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c882160d03cb281c8d64d363b3e42273543f2f7f
Stats:     289 lines in 6 files changed: 0 ins; 283 del; 6 mod

8344966: Remove the allowNonPublic MBean compatibility property

Reviewed-by: amenkov, sspitsyn, dfuchs

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

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

From kevinw at openjdk.org  Thu Jan 23 09:32:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 09:32:51 GMT
Subject: Integrated: 8344969: Remove the jmx.mxbean.multiname compatibility
 property
In-Reply-To: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
References: <0VQXZGbZ8jsarvE6Pq2_aTCzxCu3J5kgdqnuU4loUrY=.aa938f9e-3f47-4156-8a97-a18509d673d6@github.com>
Message-ID: <5tEImP_lAHvb9U7nEGaZUIrOoyx5_H_vkexX4Vc6yqs=.7cab54dd-b37d-42b5-bc2e-fea3ad61d5a2@github.com>

On Wed, 15 Jan 2025 10:59:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.mxbean.multiname" which was introduced in JDK-7 for compatibility with code which may have depended on previous incorrect behaviour.  Removal is long overdue.

This pull request has now been integrated.

Changeset: 3069e912
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3069e91232e33c1d8570378f93a54ac6a036f11f
Stats:     21 lines in 2 files changed: 0 ins; 15 del; 6 mod

8344969: Remove the jmx.mxbean.multiname compatibility property

Reviewed-by: sspitsyn, amenkov, dfuchs

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

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

From kevinw at openjdk.org  Thu Jan 23 11:08:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 11:08:52 GMT
Subject: Integrated: 8345048: Remove the jmx.extend.open.types compatibility
 property
In-Reply-To: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
References: <w99iMo0npCgDlchxT1LIw4XTES70fpGe2ZMIkpmdCWw=.812ef52d-f3fb-4ee7-b53c-2ce284ce93af@github.com>
Message-ID: <Oy-KaEEedQVlAB-BuL-46dOc-qjwDYRPPly69XtOjNw=.af79081f-0025-4f2b-a2b5-62ed97414437@github.com>

On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Classes should not override javax.management.openmbean.OpenType.getClassName(), and this was made illegal (caused an Exception) in JDK6.  A System Property jmx.extend.open.types was introduced to allow such an override, for compatibility reasons.
> 
> This was not documented but was mentioned in the Exception message.
> 
> This compatibility convenience flag should be removed.

This pull request has now been integrated.

Changeset: 119899bc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/119899bc69a5936d2e38065d8a05705c6d37e66f
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8345048: Remove the jmx.extend.open.types compatibility property

Reviewed-by: cjplummer, amenkov, sspitsyn

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

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

From kevinw at openjdk.org  Thu Jan 23 11:41:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 11:41:53 GMT
Subject: Integrated: 8345045: Remove the jmx.remote.x.buffer.size JMX
 notification property
In-Reply-To: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
References: <npMKL_JE-yexVCFkyVQB8SG1fzEYcyo-dyELw3J5brA=.60835efc-4e25-4cbd-90f8-fcfdf71c7fc1@github.com>
Message-ID: <itTcag82mIzsjtMnF9JvWnmMnWwC6o_0Q_59PsJnAm0=.1b1655bc-fb1e-46bb-bcb2-875bf8584f5f@github.com>

On Thu, 16 Jan 2025 10:31:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> jmx.remote.x.buffer.size was a previous and incorrect name for the jmx.remote.x.notification.buffer.size property.  
> 
> The old name was still recognised to aid compatibility.
> That was 2004.  We should only recognise the correct name at this point.

This pull request has now been integrated.

Changeset: 8b46db0c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b46db0c0d71dd7c76078028fa2600dd0cc08387
Stats:     33 lines in 2 files changed: 0 ins; 24 del; 9 mod

8345045: Remove the jmx.remote.x.buffer.size JMX notification property

Reviewed-by: amenkov, sspitsyn

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

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

From kevinw at openjdk.org  Thu Jan 23 11:43:54 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 11:43:54 GMT
Subject: Integrated: 8345049: Remove the jmx.tabular.data.hash.map
 compatibility property
In-Reply-To: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
References: <NiOewUHFO-M5Le_3NQGsHIXRqw8agpBjqLV5JnyXcsc=.ece61fed-76c4-4799-b0ac-39abdd7e4ec7@github.com>
Message-ID: <5v_ix7U9xD8aGX8LlNAJtUBi0r91rPd0hfl9Oy3znCs=.568c1074-7fc4-466f-b377-131d02fc26c3@github.com>

On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove the System Property "jmx.tabular.data.hash.map" which was introduced historically for JMX compatibility with JDK 1.3 clients.

This pull request has now been integrated.

Changeset: c00557f8
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c00557f8f53ff729c8a1857a4ffcc585d3f8c6c4
Stats:     50 lines in 2 files changed: 0 ins; 47 del; 3 mod

8345049: Remove the jmx.tabular.data.hash.map compatibility property

Reviewed-by: cjplummer, sspitsyn, dfuchs

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

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

From rriggs at openjdk.org  Thu Jan 23 14:27:50 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 23 Jan 2025 14:27:50 GMT
Subject: RFR: 8348265: RMIConnectionImpl: Remove Subject.callAs on
 MarshalledObject
In-Reply-To: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
References: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
Message-ID: <cOoTS2bjOP-ol5Npdq_M5ojqlAvuNxZVpOI3PrOMETs=.44f93d7a-046a-4217-91a1-837090711159@github.com>

On Wed, 22 Jan 2025 10:05:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Redundant after Security Manager removal, remove the Subject.callAs() call on a MashalledObject.cast().
> Previously, a Policy could possibly have restricted permissable classes available to the cast().
> 
> Nothing in our tests fails if we remove the callAs.
> 
> Also fixing a comment typo ("reqIncomming") and rewording that comment.

Makes sense to me (to drop the callAs).
With an SM (and policy) it might allow as cast to a class that would have been restricted by policy.
Without the SM the subject can?t affect the cast.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23230#pullrequestreview-2570012725

From kevinw at openjdk.org  Thu Jan 23 14:30:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 14:30:47 GMT
Subject: RFR: 8348265: RMIConnectionImpl: Remove Subject.callAs on
 MarshalledObject
In-Reply-To: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
References: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
Message-ID: <o1-D4L2N3oFMAgi2oBEisSmKp7UpKSarfrRybv4cCkw=.33026859-0e89-4ded-abf6-f3bed49d5cf3@github.com>

On Wed, 22 Jan 2025 10:05:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Redundant after Security Manager removal, remove the Subject.callAs() call on a MashalledObject.cast().
> Previously, a Policy could possibly have restricted permissable classes available to the cast().
> 
> Nothing in our tests fails if we remove the callAs.
> 
> Also fixing a comment typo ("reqIncomming") and rewording that comment.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23230#issuecomment-2609952658

From kevinw at openjdk.org  Thu Jan 23 15:39:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 15:39:59 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
Message-ID: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>

java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.

These deprecations should be uprated to state they are for future removal.

java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

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

Commit messages:
 - 8336017: Deprecate java.util.logging.LoggingMXBean, its implementation, and accessor method for removal

Changes: https://git.openjdk.org/jdk/pull/23271/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23271&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336017
  Stats: 12 lines in 3 files changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/23271.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23271/head:pull/23271

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

From kevinw at openjdk.org  Thu Jan 23 15:39:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Jan 2025 15:39:59 GMT
Subject: RFR: 8336017: Deprecate java.util.logging.LoggingMXBean,
 its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <v_2PhMww77NsRvtDIWfuOt7KPEtb7jVlboaLyO00q_E=.84c02fdf-c6be-4275-a0aa-e16283e947e2@github.com>

On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
> 
> These deprecations should be uprated to state they are for future removal.
> 
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.

This area is very confusing with the old redundant implementation hanging around.

The interface `java.lang.management.PlatformLoggingMXBean` is the correct management interface for logging.  As per the java.util.LogManager documentation, can be accessed using: ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class)

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

PR Comment: https://git.openjdk.org/jdk/pull/23271#issuecomment-2610129200

From hannesw at openjdk.org  Thu Jan 23 16:18:46 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 23 Jan 2025 16:18:46 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules
In-Reply-To: <LEVRzFIWyxMqJO2jn0-6OIP0olEZzb1zgUqqGjMCyZk=.19b783da-c221-46ef-b3ef-9dce7100b9af@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>
 <SHu8usWkPnJ3tmmiTXpqkqaquCeF_XjKuwHhH2psSRw=.72d2f6bb-f887-4775-b3d5-b2be3755ac00@github.com>
 <LEVRzFIWyxMqJO2jn0-6OIP0olEZzb1zgUqqGjMCyZk=.19b783da-c221-46ef-b3ef-9dce7100b9af@github.com>
Message-ID: <kr9t5crN8kAzjooBEyo2LmGxx-PhHQv3p0Ol4jIQF4Q=.d65bef3a-8164-42e5-91cd-76f8b8e51794@github.com>

On Wed, 22 Jan 2025 20:35:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Only the `writeExternal` method is required to have a `@serialData` tag in order to keep javadoc running with `-serialwarn` option from complaining. I guess the thinking is that the `readExternal` logic can be derived from that.
>> 
>> @prrace do you have any suggestions for the spec change, or are you ok with the proposed wording?
>
> There's not a great number of "good" examples of this in the JDK, so probably OK except it
> seems like most cases will do it like a normal javadoc method so you'd want an @param tag too.
> 
> note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others

I've created a CSR with a slightly modified version of the text proposed in this PR: 
https://bugs.openjdk.org/browse/JDK-8348408

Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1927261011

From kcr at openjdk.org  Thu Jan 23 16:27:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 23 Jan 2025 16:27:52 GMT
Subject: [jdk24] RFR: 8345750: Shenandoah: Test
 TestJcmdHeapDump.java#aggressive intermittent assert(gc_cause() ==
 GCCause::_no_gc) failed: Over-writing cause
In-Reply-To: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
References: <V23Fn_jJIrvF6rSmMLPbSIrOuk6BTvtrExRMVmFZJuI=.6933b100-6221-4dba-a75f-4723cbdcd130@github.com>
Message-ID: <bJY35XOxd5GMfhJKn7wLEMxFTSMQ17CHm3ZI0cfMegU=.3dd38c81-4908-4c5c-956c-29dd1cdc1322@github.com>

On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a clean backport and addresses a fairly critical issue where in a mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.

@earthling-amzn Did you see David's question? I think this should not have been integrated to jdk24 given the RDP2 rules. Was this instead intended for jdk24u (for 24.0.1)?

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

PR Comment: https://git.openjdk.org/jdk/pull/23221#issuecomment-2610302874

From cjplummer at openjdk.org  Thu Jan 23 16:50:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 16:50:07 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
Message-ID: <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>

> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
> 
> Testing:
> 
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on all supported platforms

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Some minor cleanup.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23182/files
  - new: https://git.openjdk.org/jdk/pull/23182/files/65ad54ad..2dc7a362

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

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

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

From cjplummer at openjdk.org  Thu Jan 23 16:50:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 16:50:08 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <tRFYkqpJ3E8pcw2u_t70dHJUTgwbQLwpX86dxQDpEjo=.2521f030-27bf-4401-846c-df56e0993409@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <tRFYkqpJ3E8pcw2u_t70dHJUTgwbQLwpX86dxQDpEjo=.2521f030-27bf-4401-846c-df56e0993409@github.com>
Message-ID: <IluDZkrQ6mWUQm7hZ3Y30F3L_aJTD3kUzxU6VYl7HyU=.50971d7b-cae5-4065-bff2-3f3490135565@github.com>

On Wed, 22 Jan 2025 07:27:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor cleanup.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 940:
> 
>> 938: 
>> 939:         if (needsSuspending) {
>> 940:             tty_message("clearStep: resuming thread");
> 
> Q: Lines: 913, 940. Should such a message printing be under the `#ifdef DEBUG` ?

Removed.

> test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 30:
> 
>> 28:  * @bug 8229012
>> 29:  * @summary Verify that during single stepping a method is not compiled and
>> 30:  *          after single stepping it is compiled..
> 
> Nit: The dots are not needed at the end.

Fixed

> test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 32:
> 
>> 30:  *          after single stepping it is compiled..
>> 31:  * @requires vm.compMode == "Xmixed"
>> 32:  * @library /test/lib /
> 
> Q: Just want to make sure the`/` at the end is not a typo. :)

Fixed. Probably I didn't fully delete a 2nd path that was copied from some other test.

> test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 228:
> 
>> 226:         /*
>> 227:          * Deal with results of test. If anything has called failure("foo")
>> 228:          * then testFailed will be true
> 
> Nit: Need dots at the end of lines: 200, 207 and 228.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1926037982
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1926038250
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1927306989
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1927299777

From cjplummer at openjdk.org  Thu Jan 23 20:21:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 20:21:24 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
Message-ID: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>

If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:


 stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)


The following can be used to reproduce this failure. Most SA tests will fail:

 make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 

I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.

I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

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

Commit messages:
 - Add DeoptimizeObjectsALotThread support

Changes: https://git.openjdk.org/jdk/pull/23279/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23279&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348239
  Stats: 82 lines in 6 files changed: 62 ins; 14 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23279.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23279/head:pull/23279

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

From dlong at openjdk.org  Thu Jan 23 22:03:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Jan 2025 22:03:46 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <sxtToa2PCVgTkpzIumkb-WdkYVfPPgzvbEz6vwwmDZE=.ed393e8a-c8c6-4617-9a18-395e5558b705@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 92:

> 90:   public boolean   isMonitorDeflationThread()    { return false; }
> 91:   public boolean   isAttachListenerThread()      { return false; }
> 92:   public boolean   isDeoptimizeObjectsALotThread() { return false; }

Is this method used anywhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1927740178

From dlong at openjdk.org  Thu Jan 23 22:06:45 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 23 Jan 2025 22:06:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic.  That would make it easier to register private types, or even types outside of libjvm.

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

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571122889

From cjplummer at openjdk.org  Thu Jan 23 22:33:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 23 Jan 2025 22:33:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
Message-ID: <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>

On Thu, 23 Jan 2025 22:03:45 GMT, Dean Long <dlong at openjdk.org> wrote:

> Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.

I'm not too sure what you are suggesting here.

> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java line 92:
> 
>> 90:   public boolean   isMonitorDeflationThread()    { return false; }
>> 91:   public boolean   isAttachListenerThread()      { return false; }
>> 92:   public boolean   isDeoptimizeObjectsALotThread() { return false; }
> 
> Is this method used anywhere?

No, but I added it to be consistent with all the other JavaThread subclasses. Actually none of these are used except for isCompilerThread and isCodeCacheSweeperThread. The latter reference is irrelevant since there is no longer a CodeCacheSweeperThread, and the former reference should be replaced with isHiddenFromExternalView(). These are all things documented to fix as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347), but in the meantime I though it best to be consistent with existing code.

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

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2611148710
PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1927768244

From dholmes at openjdk.org  Fri Jan 24 06:35:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 24 Jan 2025 06:35:48 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <J5r63DXbAL3sKyHad22LYgpMWab6i3b8YOZprE-mu3Y=.8109ec0a-cfd6-4b38-bc27-79b2560279b6@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Okay as a quick fix but I look forward to all this going away.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571746144

From lmesnik at openjdk.org  Fri Jan 24 06:38:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Jan 2025 06:38:49 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <JT7-1s8_PWX8dVD-XoP72nTT-FWJbKAfD6oqwn-jcko=.0f9d3f0b-d205-4a4c-89a7-bc34f208c5e6@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2571749964

From kevinw at openjdk.org  Fri Jan 24 08:42:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 08:42:55 GMT
Subject: Integrated: 8348265: RMIConnectionImpl: Remove Subject.callAs on
 MarshalledObject
In-Reply-To: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
References: <NpXXv2-kH2XiG2CMhERsuAbUO5wHWPOfjsxv4psTfew=.0ab6b002-3ea6-488c-b1ee-0adc07f529cf@github.com>
Message-ID: <dGMMddQ6obhE5Ld0MhiZu_m62nUnYL9B2-dfG8kvddg=.d1b2359c-e571-4cc7-84f3-f726d5f13b95@github.com>

On Wed, 22 Jan 2025 10:05:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Redundant after Security Manager removal, remove the Subject.callAs() call on a MashalledObject.cast().
> Previously, a Policy could possibly have restricted permissable classes available to the cast().
> 
> Nothing in our tests fails if we remove the callAs.
> 
> Also fixing a comment typo ("reqIncomming") and rewording that comment.

This pull request has now been integrated.

Changeset: a09f06d5
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a09f06d538075bcdd7cce6da9c3bf9549ce7d543
Stats:     15 lines in 1 file changed: 0 ins; 13 del; 2 mod

8348265: RMIConnectionImpl: Remove Subject.callAs on MarshalledObject

Reviewed-by: rriggs

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

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

From kevinw at openjdk.org  Fri Jan 24 10:21:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 10:21:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:

> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
> 168:       ServiceThread. The latter seven subclasses of the former. Most operations

The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1928457607

From kevinw at openjdk.org  Fri Jan 24 10:25:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 10:25:45 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <tzhNl0atcSwmopzzmLMbW5sfpIV5gawT7T4MzMz0oyg=.55d1f427-e5dd-401a-a771-3d60538d161b@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2572270646

From hannesw at openjdk.org  Fri Jan 24 10:58:24 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 24 Jan 2025 10:58:24 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
Message-ID: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>

> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
> 
> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
> 
> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
> 
> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Update @serialData text to CSR-approved version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22980/files
  - new: https://git.openjdk.org/jdk/pull/22980/files/c4be23a7..b686fb10

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

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

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

From syan at openjdk.org  Fri Jan 24 11:47:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 24 Jan 2025 11:47:15 GMT
Subject: RFR: 8348567: [ASAN] Memory access partially overflows by
 NativeCallStack
Message-ID: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>

Hi all,
This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes' testcase 
locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file when call `NativeCallStack::NativeCallStack` function. Before this PR, 'CollisionsReceiveDifferentIndexes' test allocate 4 type variable `i` and then pass the address `&i`, but in 'NativeCallStack' function read the pointer as 8 types, so the AddressSanitizer report "Memory access partially overflows variable i". This PR change the variable `i` to `size_t` to avoid this undefined behaviour.
Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8348567: [ASAN] Memory access partially overflows by NativeCallStack

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

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

From sspitsyn at openjdk.org  Fri Jan 24 11:49:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Jan 2025 11:49:47 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
In-Reply-To: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
Message-ID: <OAiJXTSBzaUDLMtU6W5L50_xSyyR6UMaWpESb4_iH7Y=.68c99171-df05-47ab-8f6d-abe46dc8d8da@github.com>

On Wed, 15 Jan 2025 12:15:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
> 
> It should be removed.

Looks good modulo copyright year.

test/jdk/javax/management/Introspector/InvokeGettersTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved.

The year 2022 looks like a typo.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23132#pullrequestreview-2572435558
PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1928559402

From sspitsyn at openjdk.org  Fri Jan 24 11:54:47 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Jan 2025 11:54:47 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>
Message-ID: <Vefsmem4Y_oStwm6tRmixU6DxxCS9RgJGa1x0pcu9Fg=.6a5a4808-ae3e-4407-a7aa-09f917321b08@github.com>

On Thu, 23 Jan 2025 16:50:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some minor cleanup.

Marked as reviewed by sspitsyn (Reviewer).

src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 913:

> 911: 
> 912:         if (needsSuspending) {
> 913:             tty_message("clearStep: suspending thread");

Nit: This `tty_message()` is still here. Should it be at least under `#ifdef DEBUG`?

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

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2572446675
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1928565847

From kevinw at openjdk.org  Fri Jan 24 11:55:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 11:55:23 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v2]
In-Reply-To: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
Message-ID: <RbRM3gOP_F9630mVQNBaApcOAgQOraYgDQ4D9PBiK6g=.49128306-81b3-4122-9fc5-4b2ae4b62c45@github.com>

> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
> 
> It should be removed.

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

  (C)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23132/files
  - new: https://git.openjdk.org/jdk/pull/23132/files/99ff70d2..381bd44d

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

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

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

From kevinw at openjdk.org  Fri Jan 24 11:55:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 11:55:23 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v2]
In-Reply-To: <OAiJXTSBzaUDLMtU6W5L50_xSyyR6UMaWpESb4_iH7Y=.68c99171-df05-47ab-8f6d-abe46dc8d8da@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <OAiJXTSBzaUDLMtU6W5L50_xSyyR6UMaWpESb4_iH7Y=.68c99171-df05-47ab-8f6d-abe46dc8d8da@github.com>
Message-ID: <IhCPGUJWeqY6dkfM4q-DxopBuCIpOYRXQbZuILA8whU=.46150c5a-bc52-4de1-b7c4-98cdde5101b5@github.com>

On Fri, 24 Jan 2025 11:45:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C)
>
> test/jdk/javax/management/Introspector/InvokeGettersTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2005, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> The year 2022 looks like a typo.

thanks, well spotted!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1928564636

From hannesw at openjdk.org  Fri Jan 24 14:42:47 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 24 Jan 2025 14:42:47 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <kr9t5crN8kAzjooBEyo2LmGxx-PhHQv3p0Ol4jIQF4Q=.d65bef3a-8164-42e5-91cd-76f8b8e51794@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <vV-L1-MeW7GAUNPqoFtoVf_EMjXzaygSf2mZgtp4KwU=.d7c1393b-c7d4-4efc-bfd0-bb548f2f0458@github.com>
 <SHu8usWkPnJ3tmmiTXpqkqaquCeF_XjKuwHhH2psSRw=.72d2f6bb-f887-4775-b3d5-b2be3755ac00@github.com>
 <LEVRzFIWyxMqJO2jn0-6OIP0olEZzb1zgUqqGjMCyZk=.19b783da-c221-46ef-b3ef-9dce7100b9af@github.com>
 <kr9t5crN8kAzjooBEyo2LmGxx-PhHQv3p0Ol4jIQF4Q=.d65bef3a-8164-42e5-91cd-76f8b8e51794@github.com>
Message-ID: <omN3vTcF_rVWoewFbTZTN9AWxW1ykqW6XIdozMN5OIw=.b959abe7-a83b-459b-ba11-eb686d36e69b@github.com>

On Thu, 23 Jan 2025 16:16:03 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> There's not a great number of "good" examples of this in the JDK, so probably OK except it
>> seems like most cases will do it like a normal javadoc method so you'd want an @param tag too.
>> 
>> note : this is a desktop class, so I'm looking at this one but someone else will need to look at all the others
>
> I've created a CSR with a slightly modified version of the text proposed in this PR: 
> https://bugs.openjdk.org/browse/JDK-8348408
> 
> Other doc tags such as `@param` and `@throws` are inherited from the overridden method. Also, this is the only change in this PR that modifies the serialization spec.

CSR was approved, and I updated the PR with the slightly modified spec text from the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22980#discussion_r1928785006

From cjplummer at openjdk.org  Fri Jan 24 20:09:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:09:31 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v3]
In-Reply-To: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
Message-ID: <7upn_ROzdjBwZNgmj_EIXSVcoVIQRvIQVc3y1sM__lw=.daaa9908-b9e4-4bb3-99e4-48b5d6a6977b@github.com>

> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
> 
> Testing:
> 
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on all supported platforms

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  get rid of debugging printf.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23182/files
  - new: https://git.openjdk.org/jdk/pull/23182/files/2dc7a362..877dce6f

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

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

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

From cjplummer at openjdk.org  Fri Jan 24 20:09:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:09:31 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <Vefsmem4Y_oStwm6tRmixU6DxxCS9RgJGa1x0pcu9Fg=.6a5a4808-ae3e-4407-a7aa-09f917321b08@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>
 <Vefsmem4Y_oStwm6tRmixU6DxxCS9RgJGa1x0pcu9Fg=.6a5a4808-ae3e-4407-a7aa-09f917321b08@github.com>
Message-ID: <Aivhja_6xPVjv8NX3N5wJQLAy0e3o1ry3MkHhvT7f_4=.4aa965a0-13b8-4d48-8f75-7dccdb889c1f@github.com>

On Fri, 24 Jan 2025 11:52:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some minor cleanup.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 913:
> 
>> 911: 
>> 912:         if (needsSuspending) {
>> 913:             tty_message("clearStep: suspending thread");
> 
> Nit: This `tty_message()` is still here. Should it be at least under `#ifdef DEBUG`?

It's gone. Are you sure you are looking at the latest sources?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929176082

From cjplummer at openjdk.org  Fri Jan 24 20:09:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:09:31 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <Aivhja_6xPVjv8NX3N5wJQLAy0e3o1ry3MkHhvT7f_4=.4aa965a0-13b8-4d48-8f75-7dccdb889c1f@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>
 <Vefsmem4Y_oStwm6tRmixU6DxxCS9RgJGa1x0pcu9Fg=.6a5a4808-ae3e-4407-a7aa-09f917321b08@github.com>
 <Aivhja_6xPVjv8NX3N5wJQLAy0e3o1ry3MkHhvT7f_4=.4aa965a0-13b8-4d48-8f75-7dccdb889c1f@github.com>
Message-ID: <upJXgGifEEmzhdYtb_uY3-shtS5yhVH2QVwFyVBlV6U=.b33f6c89-b262-4250-9c91-500632ca9b5c@github.com>

On Fri, 24 Jan 2025 20:02:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 913:
>> 
>>> 911: 
>>> 912:         if (needsSuspending) {
>>> 913:             tty_message("clearStep: suspending thread");
>> 
>> Nit: This `tty_message()` is still here. Should it be at least under `#ifdef DEBUG`?
>
> It's gone. Are you sure you are looking at the latest sources?

Hmm. Now it looks like it is there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929176909

From cjplummer at openjdk.org  Fri Jan 24 20:09:31 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:09:31 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v2]
In-Reply-To: <upJXgGifEEmzhdYtb_uY3-shtS5yhVH2QVwFyVBlV6U=.b33f6c89-b262-4250-9c91-500632ca9b5c@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <dC2xbjfUIj9mpFGeh_v6peojb8BbgU5k6Ak_ygEyFuw=.129bc93a-515a-409c-b575-5cc66b4abb3e@github.com>
 <Vefsmem4Y_oStwm6tRmixU6DxxCS9RgJGa1x0pcu9Fg=.6a5a4808-ae3e-4407-a7aa-09f917321b08@github.com>
 <Aivhja_6xPVjv8NX3N5wJQLAy0e3o1ry3MkHhvT7f_4=.4aa965a0-13b8-4d48-8f75-7dccdb889c1f@github.com>
 <upJXgGifEEmzhdYtb_uY3-shtS5yhVH2QVwFyVBlV6U=.b33f6c89-b262-4250-9c91-500632ca9b5c@github.com>
Message-ID: <6jVT1W0ByFJawvfPGLcJ9WThZv35DzDHP2y_sUDoGB8=.94f2829b-6464-436e-8340-1641f171162e@github.com>

On Fri, 24 Jan 2025 20:03:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> It's gone. Are you sure you are looking at the latest sources?
>
> Hmm. Now it looks like it is there.

I see now. I got rid one for resuming but not the one for suspending. It should be gone now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929178668

From cjplummer at openjdk.org  Fri Jan 24 20:15:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:15:49 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
In-Reply-To: <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
Message-ID: <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>

On Fri, 24 Jan 2025 10:19:30 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:
> 
>> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
>> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
>> 168:       ServiceThread. The latter seven subclasses of the former. Most operations
> 
> The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."

Yes, it should be updated to eight, but I think what would be better is "returns objects of type JavaThraed or one of its subclasses..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1929185927

From cjplummer at openjdk.org  Fri Jan 24 20:22:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:22:07 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23279/files
  - new: https://git.openjdk.org/jdk/pull/23279/files/8ba5e23a..5779c9eb

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

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

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

From cjplummer at openjdk.org  Fri Jan 24 20:22:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:22:07 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <TIdNnxTG7pqGZa6knY80iOp0xjtmfFCt1TRQUcHKG8A=.cca77d61-c285-45fe-8d14-db2173b46ac2@github.com>
 <xqTf-pvHCfg_l7X-ltKhWvg33zaNJVmEWjatLVLb-DI=.a5fa3185-3a78-402f-b079-214544cca3c1@github.com>
Message-ID: <K2qxJO4zLE7N9nEuihbK9Su17XFsuPqWyFEjr6dvk6Y=.89c33ab4-176e-40da-bc25-b3bed1a8ab2a@github.com>

On Fri, 24 Jan 2025 20:13:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 168:
>> 
>>> 166:       JvmtiAgentThread, NotificationThread, MonitorDeflationThread,
>>> 167:       StringDedupThread, AttachListenerThread, DeoptimizeObjectsALotThread and
>>> 168:       ServiceThread. The latter seven subclasses of the former. Most operations
>> 
>> The latter eight are subclasses of the former? 8-) Or just "JavaThread, or its subclasses..."
>
> Yes, it should be updated to eight, but I think what would be better is "returns objects of type JavaThraed or one of its subclasses..."

Ok, it's fixed now. I stuck with a somewhat minimal update mostly just to resolve the incorrect count. This comment may have further cleanup as part of [JDK-8348347](https://bugs.openjdk.org/browse/JDK-8348347).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23279#discussion_r1929190501

From cjplummer at openjdk.org  Fri Jan 24 20:33:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 20:33:47 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v2]
In-Reply-To: <RbRM3gOP_F9630mVQNBaApcOAgQOraYgDQ4D9PBiK6g=.49128306-81b3-4122-9fc5-4b2ae4b62c45@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <RbRM3gOP_F9630mVQNBaApcOAgQOraYgDQ4D9PBiK6g=.49128306-81b3-4122-9fc5-4b2ae4b62c45@github.com>
Message-ID: <IZQpZ-jFlLrPSsL2F1oecj6rDFUP3GOM9_Fl01zAuXo=.1568fb52-29f8-4911-a14d-b830a56a0f21@github.com>

On Fri, 24 Jan 2025 11:55:23 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
>> 
>> It should be removed.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java line 149:

> 147:             throws MBeanException, ReflectionException {
> 148: 
> 149:         // Construct the exception that we will throw

Although your changes look fine, the existing code for constructing this exception is odd in that it artificially introduces a `cause` exception.  It seems to mostly want to capture additional msg information, but most of it seems to be duplicated in the msg passed in, and all this could instead just  be handled with a single msg constructed at the call site (and the ReflectionException could be allocated at the call site). Also, what it the @SuppressWarnings("removal") for?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1929200951

From dlong at openjdk.org  Fri Jan 24 22:54:51 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 24 Jan 2025 22:54:51 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
Message-ID: <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>

On Thu, 23 Jan 2025 22:30:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.
> 
> I'm not too sure what you are suggesting here.

For example, instead of a single table, allow multiple tables.  They could be registered with with an API similar to JNI RegisterNatives.

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

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613547838

From kevinw at openjdk.org  Fri Jan 24 22:58:47 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 22:58:47 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
Message-ID: <IZASOZekd_Rg1q9Ab0cn1Dc5Tmo63jezhMi-0O01xts=.05e7d0ec-0013-4e0a-bc83-c334e8657762@github.com>

On Fri, 24 Jan 2025 20:22:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup comment

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23279#pullrequestreview-2573741547

From cjplummer at openjdk.org  Fri Jan 24 23:26:46 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 24 Jan 2025 23:26:46 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
 <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
Message-ID: <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>

On Fri, 24 Jan 2025 22:52:19 GMT, Dean Long <dlong at openjdk.org> wrote:

> > > Overall the changes seem fine, however it would be nice if the vmStructs.cpp registration mechanism was modular and extensible, instead of monolithic. That would make it easier to register private types, or even types outside of libjvm.
> > 
> > 
> > I'm not too sure what you are suggesting here.
> 
> For example, instead of a single table, allow multiple tables. They could be registered with with an API similar to JNI RegisterNatives.

I don't see how that relates to this change. It sounds more like a general suggestion to overhaul of how vmStructs is implemented.

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

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613584454

From schernyshev at openjdk.org  Fri Jan 24 23:38:50 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 24 Jan 2025 23:38:50 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>
Message-ID: <knOpK9B2ydGHdm9FKfmpZrcpVNHZtYcVy4gH9mcCIkU=.c98ec1ae-a530-4e5a-9545-80519da9901c@github.com>

On Thu, 12 Dec 2024 01:11:33 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added details in the log message

Hi Jonas,
The PR is now ready and under review. I couldn't get back to it earlier due
to ongoing work. Apologies for the delay.

Am Fr., 24. Jan. 2025 um 11:07 Uhr schrieb Jonas ***@***.***>:

> Hi @sercher <https://github.com/sercher> and @jerboaa
> <https://github.com/jerboaa> may I ask what the current state of this PR
> is, because we are waiting for the bug fix?
>
> ?
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jdk/pull/21808#issuecomment-2612141043>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABQZGCH4R4TSK7UERVL73Y32MIGHBAVCNFSM6AAAAABQ6PM7YSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJSGE2DCMBUGM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2613597123

From kevinw at openjdk.org  Fri Jan 24 23:53:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 24 Jan 2025 23:53:46 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v2]
In-Reply-To: <IZQpZ-jFlLrPSsL2F1oecj6rDFUP3GOM9_Fl01zAuXo=.1568fb52-29f8-4911-a14d-b830a56a0f21@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <RbRM3gOP_F9630mVQNBaApcOAgQOraYgDQ4D9PBiK6g=.49128306-81b3-4122-9fc5-4b2ae4b62c45@github.com>
 <IZQpZ-jFlLrPSsL2F1oecj6rDFUP3GOM9_Fl01zAuXo=.1568fb52-29f8-4911-a14d-b830a56a0f21@github.com>
Message-ID: <SrQawKIAWjQz_4KAXGLK_LjjKg3oswdiTYgnmV588tM=.c3563553-5a39-4660-97eb-b334c1bcceb0@github.com>

On Fri, 24 Jan 2025 20:31:01 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   (C)
>
> src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java line 149:
> 
>> 147:             throws MBeanException, ReflectionException {
>> 148: 
>> 149:         // Construct the exception that we will throw
> 
> Although your changes look fine, the existing code for constructing this exception is odd in that it artificially introduces a `cause` exception.  It seems to mostly want to capture additional msg information, but most of it seems to be duplicated in the msg passed in, and all this could instead just  be handled with a single msg constructed at the call site (and the ReflectionException could be allocated at the call site). Also, what it the @SuppressWarnings("removal") for?

Thanks -
  
Ah, "removal" was added  for SM removal, that can surely go now.  Actually I don't see anything in what we're removing which required it, seems to have been unnecessary.

The method is almost trivial now, and only used in two places.  Yes it is a bit odd to manufacture a new cause, rather than throw something immediately.

Elsewhere in this file, e.g. the getAttribute method does just throw new AttributeNotFoundException(msg),
but here in invoke() we use "return noSuchMethod(...)" which effectively does:

  throw new ReflectionException(new NoSuchMethodException(operation + sigString(signature)), msg);

(Hah, yes unlike a new Exception(String message, Throwable cause), ReflectionException uses new ReflectionException(Exception e, String message).)

Two lines like that mean that the noSuchMethod method can be removed.  I'm trying that out...

But changing the behaviour (throwing a different Exception) might come with some compatibilty risk.  I think it's good not to change the behaviour in this property removal change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1929381074

From dlong at openjdk.org  Sat Jan 25 01:29:47 2025
From: dlong at openjdk.org (Dean Long)
Date: Sat, 25 Jan 2025 01:29:47 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <feqhh4FKUzp4wvcRUqi9jPv6-eyjLHEhT5zYeVI8zzo=.a3c562d0-37a1-4e8b-a8a9-40cb633635b3@github.com>
 <yFE1mJW1tl5s40TI89DsjDvd0JSbPE25I189-SxSjZg=.75d8d213-a5a0-4eef-8315-803cf718d6d5@github.com>
 <HQlT0k_cC6fh2GBZZpl2wNREhuQTANK-NfqtP3Xsw-k=.20abae09-54f2-4681-96e7-bc88a610c9fd@github.com>
 <O3pxJ-hCpGKGo7TDrzqBhPHnstCu_gHHcLwJSBmjqt4=.e647ecea-75a0-4393-94c9-1278a9f728cf@github.com>
Message-ID: <1i5RWKGP-ICfyoE21UB2OQT5QTkU6dGHPmzLW9o3-ME=.75b5a4f5-7bc1-4629-9775-8f3aa37fc257@github.com>

On Fri, 24 Jan 2025 23:23:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I don't see how that relates to this change. It sounds more like a general suggestion to overhaul of how vmStructs is implemented.

It relates because if something like that was available then we could register types that are local to a .cpp file without moving them to a .hpp first.

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

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2613705537

From aturbanov at openjdk.org  Sat Jan 25 11:51:49 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Jan 2025 11:51:49 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v3]
In-Reply-To: <7upn_ROzdjBwZNgmj_EIXSVcoVIQRvIQVc3y1sM__lw=.daaa9908-b9e4-4bb3-99e4-48b5d6a6977b@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <7upn_ROzdjBwZNgmj_EIXSVcoVIQRvIQVc3y1sM__lw=.daaa9908-b9e4-4bb3-99e4-48b5d6a6977b@github.com>
Message-ID: <AiTfRFsJwncsl6JhRSJpkTSqTPHDY-mn6Y8XsM-Mb9s=.9f16214b-1087-4c1b-8b11-7d9cc220efd4@github.com>

On Fri, 24 Jan 2025 20:09:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of debugging printf.

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 90:

> 88: 
> 89:     private static boolean isCompiled() {
> 90:         return  WB.isMethodCompiled(busyWorkMethod, true) || WB.isMethodCompiled(busyWorkMethod, false);

Suggestion:

        return WB.isMethodCompiled(busyWorkMethod, true) || WB.isMethodCompiled(busyWorkMethod, false);

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 139:

> 137:     }
> 138: 
> 139:     public static void main(String[] args)   throws Exception {

Suggestion:

    public static void main(String[] args) throws Exception {

test/jdk/com/sun/jdi/SingleStepCompilationTest.java line 214:

> 212:         try {
> 213:             addListener(this);
> 214:         } catch (Exception ex){

Suggestion:

        } catch (Exception ex) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929529080
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929529106
PR Review Comment: https://git.openjdk.org/jdk/pull/23182#discussion_r1929529136

From duke at openjdk.org  Sat Jan 25 18:49:50 2025
From: duke at openjdk.org (Jonas)
Date: Sat, 25 Jan 2025 18:49:50 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v8]
In-Reply-To: <pWWJSRLoCYOkMWwLoMBVpysmorlP0uQ5lAFqFu3umXA=.ee72e9a9-1f93-4557-b2dc-0f3d4a2ae044@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <qpI0PEaxhHvSLKRujwyDCsb8uUTQw2sQA2zomJW6cJc=.2dbb1062-31f4-401d-9a8c-46fe520895c4@github.com>
 <pWWJSRLoCYOkMWwLoMBVpysmorlP0uQ5lAFqFu3umXA=.ee72e9a9-1f93-4557-b2dc-0f3d4a2ae044@github.com>
Message-ID: <bO2XcbYJJYDu_-PyWzCLcfbdesNeOGe0kDa4gaMW7Ew=.5f846043-7008-4fc2-9901-c967c2b6ed25@github.com>

On Tue, 3 Dec 2024 10:06:39 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - update cgroup v1 in metrics
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - updated test (path is reduced)
>
> Here's the summary of the latest state of the PR. The updated code
> - special cases the condition when `_root` is `/`, and `cgroup_path` includes `../`. The condition appears in containers when a process's cgroup is moved to a supergroup. Then the cgroup files are mapped inside the container at the controller's mount point. The reason for this - path adjustment will always fail with cgroup path prefix `../`;
> - calls `stat()` on cgroup path to make sure the directory exists - only when `_root` != `/` and `_root` != `cgroup_path`. This issue is specific to cgroup v1 containers, where /proc/self/cgroup is from host, cgroup files are mapped at controller's mount point, the mapping may include subgroups that need to be walked through to locate the smallest limits ;
> - sets Java Metrics in alignment with hotspot logic ;
> - fixes an NPE in Java Metrics ;
> - fixes an uninitialized path issue in hotspot / cgroup v1 subsystem when `_root` != `/` and `_root` != `cgroup_path`;
> - fixes a logical error with `lowest_limit` in the path adjustment in `CgroupUtil::adjust_controller()` methods ;
> - adds container tests on subgroups in hotspot and metrics.

Hi @sercher and @jerboaa may I ask what the current state of this PR is, because we are waiting for the bug fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2612141043

From kevinw at openjdk.org  Sun Jan 26 20:27:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sun, 26 Jan 2025 20:27:32 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v3]
In-Reply-To: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
Message-ID: <3Q1jVD8bQ9gGR30YqpJNJowM_TYNbT7Xh5hN_CNG2Bk=.0e3fa863-8cf3-417c-a2c6-ef3970c7dfc9@github.com>

> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
> 
> It should be removed.

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - Remove noSuchMethod method
 - Remove removal warnings suppression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23132/files
  - new: https://git.openjdk.org/jdk/pull/23132/files/381bd44d..302f1dfc

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

  Stats: 22 lines in 1 file changed: 0 ins; 20 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/23132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23132/head:pull/23132

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

From kevinw at openjdk.org  Mon Jan 27 09:57:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 27 Jan 2025 09:57:48 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v2]
In-Reply-To: <SrQawKIAWjQz_4KAXGLK_LjjKg3oswdiTYgnmV588tM=.c3563553-5a39-4660-97eb-b334c1bcceb0@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <RbRM3gOP_F9630mVQNBaApcOAgQOraYgDQ4D9PBiK6g=.49128306-81b3-4122-9fc5-4b2ae4b62c45@github.com>
 <IZQpZ-jFlLrPSsL2F1oecj6rDFUP3GOM9_Fl01zAuXo=.1568fb52-29f8-4911-a14d-b830a56a0f21@github.com>
 <SrQawKIAWjQz_4KAXGLK_LjjKg3oswdiTYgnmV588tM=.c3563553-5a39-4660-97eb-b334c1bcceb0@github.com>
Message-ID: <uuUcydxGl1HO5CD7fI992kj7KiXg2BHESQABGXlcrec=.c0ea1bc9-68ca-4b7c-9e66-9cfa49737c69@github.com>

On Fri, 24 Jan 2025 23:50:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java line 149:
>> 
>>> 147:             throws MBeanException, ReflectionException {
>>> 148: 
>>> 149:         // Construct the exception that we will throw
>> 
>> Although your changes look fine, the existing code for constructing this exception is odd in that it artificially introduces a `cause` exception.  It seems to mostly want to capture additional msg information, but most of it seems to be duplicated in the msg passed in, and all this could instead just  be handled with a single msg constructed at the call site (and the ReflectionException could be allocated at the call site). Also, what it the @SuppressWarnings("removal") for?
>
> Thanks -
>   
> Ah, "removal" was added  for SM removal, that can surely go now.  Actually I don't see anything in what we're removing which required it, seems to have been unnecessary.
> 
> The method is almost trivial now, and only used in two places.  Yes it is a bit odd to manufacture a new cause, rather than throw something immediately.
> 
> Elsewhere in this file, e.g. the getAttribute method does just throw new AttributeNotFoundException(msg),
> but here in invoke() we use "return noSuchMethod(...)" which effectively does:
> 
>   throw new ReflectionException(new NoSuchMethodException(operation + sigString(signature)), msg);
> 
> (Hah, yes unlike a new Exception(String message, Throwable cause), ReflectionException uses new ReflectionException(Exception e, String message).)
> 
> Two lines like that mean that the noSuchMethod method can be removed.  I'm trying that out...
> 
> But changing the behaviour (throwing a different Exception) might come with some compatibilty risk.  I think it's good not to change the behaviour in this property removal change.

Updated with noSuchMethod method removed, and the two places t was called now create their own Exception.

This makes it clearer just how odd it is, to create a NoSuchMethodException and stash it in a ReflectionException (the invoke() method throws MBeanException, ReflectionException).

This behaviour has been here for many years and we don't really want to sneak in a behaviour change here.  But I quite like this update for the clarity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1930251123

From sspitsyn at openjdk.org  Mon Jan 27 10:25:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 27 Jan 2025 10:25:50 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v3]
In-Reply-To: <7upn_ROzdjBwZNgmj_EIXSVcoVIQRvIQVc3y1sM__lw=.daaa9908-b9e4-4bb3-99e4-48b5d6a6977b@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <7upn_ROzdjBwZNgmj_EIXSVcoVIQRvIQVc3y1sM__lw=.daaa9908-b9e4-4bb3-99e4-48b5d6a6977b@github.com>
Message-ID: <y0rl45JE5AxKj88mjqmJpJshq1hlme-7hOUqP1z5m1o=.72b93e87-9eee-42bc-b950-29054ecddf5c@github.com>

On Fri, 24 Jan 2025 20:09:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of debugging printf.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2575042483

From sspitsyn at openjdk.org  Mon Jan 27 11:30:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 27 Jan 2025 11:30:07 GMT
Subject: RFR: 8300708: some nsk jvmti tests fail with virtual thread wrapper
 due to jvmti missing some virtual thread support
Message-ID: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>

Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.

The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.

Testing:
- Ran mach5 tiers 1-5

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

Commit messages:
 - 8300708: some nsk jvmti tests fail with virtual thread wrapper due to jvmti missing some virtual thread support

Changes: https://git.openjdk.org/jdk/pull/23314/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23314&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300708
  Stats: 70 lines in 5 files changed: 19 ins; 9 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/23314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23314/head:pull/23314

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

From cjplummer at openjdk.org  Mon Jan 27 19:41:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 19:41:19 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
Message-ID: <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>

> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
> 
> Testing:
> 
> - [x] Tier1 CI
> - [x] Tier2 CI svc testing
> - [x] Tier3 CI svc testing
> - [x] Tier5 CI svc testing
> - [x] ran all svc test 10 times each on all supported platforms

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  fix white space errors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23182/files
  - new: https://git.openjdk.org/jdk/pull/23182/files/877dce6f..bbd778fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23182&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23182&range=02-03

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

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

From cjplummer at openjdk.org  Mon Jan 27 19:48:54 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 19:48:54 GMT
Subject: RFR: 8348239: SA does not know about DeoptimizeObjectsALotThread
 [v2]
In-Reply-To: <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
 <PWrxL0iDb1q2ytirw-y2TKyCUOXg3dT4BBDry9G-dEg=.3fdb257d-067e-4741-8aba-6110b46721eb@github.com>
Message-ID: <PnyY94znCsoSop44ZacpGiqqe7B4N8i4Rbc7wIg3pec=.85282e43-7854-4e7f-91fa-f735157ddccb@github.com>

On Fri, 24 Jan 2025 20:22:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
>> 
>> 
>>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> 
>> 
>> The following can be used to reproduce this failure. Most SA tests will fail:
>> 
>>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
>> 
>> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
>> 
>> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup comment

Thanks for the reviews David, Leonid, Dean, and Kevin

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

PR Comment: https://git.openjdk.org/jdk/pull/23279#issuecomment-2616740973

From cjplummer at openjdk.org  Mon Jan 27 19:48:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 19:48:55 GMT
Subject: Integrated: 8348239: SA does not know about
 DeoptimizeObjectsALotThread
In-Reply-To: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
References: <hWSVI3YyJjUutCyVzeq03E34uGfEXvxgWmahqyaMF9I=.e4ca931d-3705-4505-9ecb-bf193f9c3a71@github.com>
Message-ID: <DpsIX5P-GtJ7O2U_0H4tUk4u1gnJ4ZJL669QSRs3aAc=.d55c8190-25f3-445c-a549-29f6b0c3b258@github.com>

On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or more DeoptimizeObjectsALotThread threads. This is one of many JavaThread subclasses that SA needs to know about, but in this case it does not. When SA tries to create a mirror of one of these threads, it fails with:
> 
> 
>  stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> 
> 
> The following can be used to reproduce this failure. Most SA tests will fail:
> 
>  make test TEST=serviceability/sa TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot 
> 
> I had to move the native DeoptimizeObjectsALotThread declaration to compileBroker.hpp to make it visible to vmStructs.cpp.
> 
> I tested with the above "make test" command and ran all svc tier1, tier2, tier3, and tier5 tests.

This pull request has now been integrated.

Changeset: 21feef32
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21feef32803b2593b097fb225c7a4c7cd46525da
Stats:     87 lines in 6 files changed: 62 ins; 15 del; 10 mod

8348239: SA does not know about DeoptimizeObjectsALotThread

Reviewed-by: kevinw, dlong, dholmes, lmesnik

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

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

From cjplummer at openjdk.org  Mon Jan 27 21:15:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 21:15:47 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v3]
In-Reply-To: <3Q1jVD8bQ9gGR30YqpJNJowM_TYNbT7Xh5hN_CNG2Bk=.0e3fa863-8cf3-417c-a2c6-ef3970c7dfc9@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <3Q1jVD8bQ9gGR30YqpJNJowM_TYNbT7Xh5hN_CNG2Bk=.0e3fa863-8cf3-417c-a2c6-ef3970c7dfc9@github.com>
Message-ID: <Sr3CQf4BYnzA2woaEHHmwUSCW8rzLDw9x4D47AwuqrQ=.fb8bb5db-a2ff-43ee-a26a-da48ac3ab674@github.com>

On Sun, 26 Jan 2025 20:27:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
>> 
>> It should be removed.
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove noSuchMethod method
>  - Remove removal warnings suppression

Marked as reviewed by cjplummer (Reviewer).

src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java line 111:

> 109:         if (list == null) {
> 110:             final String msg = "No such operation: " + operation;
> 111:             throw new ReflectionException(new NoSuchMethodException(operation + sigString(signature)), msg);

I think this is much better, but I still think it's odd that `operation` is in both exceptions (after your changes it's a lot more clear that this is the case), but I'm okay with that for the sake of not risking any compatibility issues.

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

PR Review: https://git.openjdk.org/jdk/pull/23132#pullrequestreview-2576564584
PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1931194592

From cjplummer at openjdk.org  Mon Jan 27 21:30:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 27 Jan 2025 21:30:49 GMT
Subject: RFR: 8300708: some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support
In-Reply-To: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
Message-ID: <SSFQwMq0b0R2Xb5e02w4Cr2sitC3Y_5InfA69uWu9ts=.c1a2e376-e8b6-495e-8e86-e7889a0abe40@github.com>

On Mon, 27 Jan 2025 11:24:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
> 
> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
> 
> Testing:
> - Ran mach5 tiers 1-5

test/hotspot/jtreg/ProblemList-Virtual.txt line 41:

> 39: 
> 40: vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/TestDescription.java 8300708 generic-all
> 41: vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/TestDescription.java 8300708 generic-all

You still have these two unfixed tests in the problem list using the CR for this PR. Either they will need a new CR, or you will need to use a different CR for this PR.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001.java line 105:

> 103:             checkPoint();
> 104:             if (currThread.isVirtual()) {
> 105:                 out.println("meth01: skipping results check for virtual thread");

Should be "meth02". Similar issues below.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp line 78:

> 76:                 err = jvmti_env->SetLocalLong(thr, 1,
> 77:                     table[i].slot, longVal);
> 78:                 if (err != JVMTI_ERROR_NONE && !(is_virtual && err == JVMTI_ERROR_OPAQUE_FRAME)) {

Maybe add a new API called something `invalidError(err)`. Not necessary, but might be a little better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1931203559
PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1931207856
PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1931210124

From kevinw at openjdk.org  Tue Jan 28 09:21:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Jan 2025 09:21:51 GMT
Subject: RFR: 8344976: Remove the jmx.invoke.getters compatibility property
 [v3]
In-Reply-To: <Sr3CQf4BYnzA2woaEHHmwUSCW8rzLDw9x4D47AwuqrQ=.fb8bb5db-a2ff-43ee-a26a-da48ac3ab674@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
 <3Q1jVD8bQ9gGR30YqpJNJowM_TYNbT7Xh5hN_CNG2Bk=.0e3fa863-8cf3-417c-a2c6-ef3970c7dfc9@github.com>
 <Sr3CQf4BYnzA2woaEHHmwUSCW8rzLDw9x4D47AwuqrQ=.fb8bb5db-a2ff-43ee-a26a-da48ac3ab674@github.com>
Message-ID: <ieZjWOorQ02KMD-dIJ8VzSQ63PyLV5m23ZJ4ClEK2H8=.dd0909e1-0bba-4c89-af1e-b64f45aaa63a@github.com>

On Mon, 27 Jan 2025 21:12:34 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove noSuchMethod method
>>  - Remove removal warnings suppression
>
> src/java.management/share/classes/com/sun/jmx/mbeanserver/PerInterface.java line 111:
> 
>> 109:         if (list == null) {
>> 110:             final String msg = "No such operation: " + operation;
>> 111:             throw new ReflectionException(new NoSuchMethodException(operation + sigString(signature)), msg);
> 
> I think this is much better, but I still think it's odd that `operation` is in both exceptions (after your changes it's a lot more clear that this is the case), but I'm okay with that for the sake of not risking any compatibility issues.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23132#discussion_r1931797096

From kevinw at openjdk.org  Tue Jan 28 09:25:52 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Jan 2025 09:25:52 GMT
Subject: Integrated: 8344976: Remove the jmx.invoke.getters compatibility
 property
In-Reply-To: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
References: <y4Owfa7kNuGtxDb_x_SIMYivwUi8tR1seSm4eJwgEeI=.9ab076af-212b-446b-8136-3590cd92c810@github.com>
Message-ID: <AXJU4_eUpM2xY-rrAwksrweT4pnm1XXINMa2ZTfG4NM=.26cdb6e4-64ca-4468-b37d-14021eacecb8@github.com>

On Wed, 15 Jan 2025 12:15:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The System Property "jmx.invoke.getters" was added in [JDK-4949203](https://bugs.openjdk.org/browse/JDK-4949203) to optionally be compatible with a time before JDK-6, when calling invoke on getters and setters was permitted.
> 
> It should be removed.

This pull request has now been integrated.

Changeset: f71541c9
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f71541c93b814cd39c3dd253234a453e5d71f4c0
Stats:     84 lines in 2 files changed: 0 ins; 76 del; 8 mod

8344976: Remove the jmx.invoke.getters compatibility property

Reviewed-by: cjplummer, dfuchs, sspitsyn

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

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

From mbaesken at openjdk.org  Tue Jan 28 10:20:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 28 Jan 2025 10:20:47 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v3]
In-Reply-To: <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
Message-ID: <XqCniUg06X1oKYBAWGB40f7lhPlLlwnfN_GEOyNpXok=.be68682b-46f9-40b9-9af3-d65898555f66@github.com>

On Thu, 23 Jan 2025 09:07:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check doSleep in launch

I added more output as suggested and check doSleep in launch; are you  fine with latest version ?

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

PR Comment: https://git.openjdk.org/jdk/pull/23213#issuecomment-2618573006

From sspitsyn at openjdk.org  Tue Jan 28 12:57:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Jan 2025 12:57:22 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v2]
In-Reply-To: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
Message-ID: <JxBuUfN7f37pX6jLRJxwnbg98vT_L2bWpV-qBQAdOFA=.610eb6ac-54d8-4b64-ad23-960d495b23b6@github.com>

> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
> 
> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
> 
> Testing:
> - Ran mach5 tiers 1-5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: replace bug number in a couple of problem-list entries

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23314/files
  - new: https://git.openjdk.org/jdk/pull/23314/files/48ec613d..2d0b032f

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

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

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

From sspitsyn at openjdk.org  Tue Jan 28 12:57:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Jan 2025 12:57:22 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v2]
In-Reply-To: <SSFQwMq0b0R2Xb5e02w4Cr2sitC3Y_5InfA69uWu9ts=.c1a2e376-e8b6-495e-8e86-e7889a0abe40@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
 <SSFQwMq0b0R2Xb5e02w4Cr2sitC3Y_5InfA69uWu9ts=.c1a2e376-e8b6-495e-8e86-e7889a0abe40@github.com>
Message-ID: <VBbbxWfGj9dNHKExkiQmSrZa7o49-T9vRhSf0mfy8tM=.c1fa33ca-8d1e-424b-ab2c-4d27f4145914@github.com>

On Mon, 27 Jan 2025 21:21:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: replace bug number in a couple of problem-list entries
>
> test/hotspot/jtreg/ProblemList-Virtual.txt line 41:
> 
>> 39: 
>> 40: vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/TestDescription.java 8300708 generic-all
>> 41: vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/TestDescription.java 8300708 generic-all
> 
> You still have these two unfixed tests in the problem list using the CR for this PR. Either they will need a new CR, or you will need to use a different CR for this PR.

Thanks. I've created a new bug and replaced the bug number in these entries:
  [8348844](https://bugs.openjdk.org/browse/JDK-8348844): Remove remaining JVMTI tests from ProblemList-Virtual, use require instead

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001.java line 105:
> 
>> 103:             checkPoint();
>> 104:             if (currThread.isVirtual()) {
>> 105:                 out.println("meth01: skipping results check for virtual thread");
> 
> Should be "meth02". Similar issues below.

Thanks. Fixed now.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp line 78:
> 
>> 76:                 err = jvmti_env->SetLocalLong(thr, 1,
>> 77:                     table[i].slot, longVal);
>> 78:                 if (err != JVMTI_ERROR_NONE && !(is_virtual && err == JVMTI_ERROR_OPAQUE_FRAME)) {
> 
> Maybe add a new API called something `invalidError(err)`. Not necessary, but might be a little better.

Thanks. I was also thinking about this but was not sure it is worth it.
Will update now as there are two of us now. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1932110589
PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1932113713
PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1932116105

From sspitsyn at openjdk.org  Tue Jan 28 14:08:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Jan 2025 14:08:26 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v3]
In-Reply-To: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
Message-ID: <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>

> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
> 
> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
> 
> Testing:
> - Ran mach5 tiers 1-5

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: correct typo in log messages; refactor error checking/reporting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23314/files
  - new: https://git.openjdk.org/jdk/pull/23314/files/2d0b032f..59df8de9

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

  Stats: 182 lines in 4 files changed: 29 ins; 122 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/23314.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23314/head:pull/23314

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

From sspitsyn at openjdk.org  Tue Jan 28 14:08:26 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Jan 2025 14:08:26 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v3]
In-Reply-To: <VBbbxWfGj9dNHKExkiQmSrZa7o49-T9vRhSf0mfy8tM=.c1fa33ca-8d1e-424b-ab2c-4d27f4145914@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
 <SSFQwMq0b0R2Xb5e02w4Cr2sitC3Y_5InfA69uWu9ts=.c1a2e376-e8b6-495e-8e86-e7889a0abe40@github.com>
 <VBbbxWfGj9dNHKExkiQmSrZa7o49-T9vRhSf0mfy8tM=.c1fa33ca-8d1e-424b-ab2c-4d27f4145914@github.com>
Message-ID: <i6fzGCn_OfOpwT-iKAXuesuOhdnuWDrhM8wlWXb3T2c=.02ab6e2a-d7cf-4dac-920f-53b615b805d7@github.com>

On Tue, 28 Jan 2025 12:54:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetLocalVariable/setlocal001/setlocal001.cpp line 78:
>> 
>>> 76:                 err = jvmti_env->SetLocalLong(thr, 1,
>>> 77:                     table[i].slot, longVal);
>>> 78:                 if (err != JVMTI_ERROR_NONE && !(is_virtual && err == JVMTI_ERROR_OPAQUE_FRAME)) {
>> 
>> Maybe add a new API called something `invalidError(err)`. Not necessary, but might be a little better.
>
> Thanks. I was also thinking about this but was not sure it is worth it.
> Will update now as there are two of us now. :)

Refactored now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23314#discussion_r1932229188

From sspitsyn at openjdk.org  Tue Jan 28 17:56:55 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 28 Jan 2025 17:56:55 GMT
Subject: RFR: 8229012: When single stepping,
 the debug agent can cause the thread to remain in interpreter mode after
 single stepping completes [v4]
In-Reply-To: <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
References: <weouT76LQB7IF7l9Ydk2ffeQ7SGdmhmuzmi5zrvfjlo=.81fd347f-c3d3-43fd-b9cc-ed3f9a32590e@github.com>
 <HZKDj6_4Dx81eGkK1QyUPcpo66QKj2eHOKgNXgJbh_0=.23bae461-b41f-436b-93fc-26383ec2c439@github.com>
Message-ID: <1H2RvCDeLfsWJmCPzVMMdj6rs-hg_FFUABhg2msKu6Q=.819ad367-ae55-4bd8-9b7a-919fa18dc921@github.com>

On Mon, 27 Jan 2025 19:41:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> When doing a  STEP_OVER, the debug agent does a NotifyFramePop() on the current frame as a safety net. After the STEP_OVER completes, the NotifyFramePop() is usually still in place. This keeps the thread in interp_only mode, which hurts performance. JVMTI has added a new ClearAllFramePops() API to allow clearing of the NotifyFramePop() and normal performance to resume.
>> 
>> Testing:
>> 
>> - [x] Tier1 CI
>> - [x] Tier2 CI svc testing
>> - [x] Tier3 CI svc testing
>> - [x] Tier5 CI svc testing
>> - [x] ran all svc test 10 times each on all supported platforms
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix white space errors.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23182#pullrequestreview-2579034571

From cjplummer at openjdk.org  Tue Jan 28 19:21:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Jan 2025 19:21:19 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after JDK-8348239
Message-ID: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>

DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:

       virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);

But is conditionally included in VMStructs:

         DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
          declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 

There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:

 Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 

The fix is to not add it to the mapping table if it is not present in the database.

Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.

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

Commit messages:
 - fix DeoptimizeObjectsALotThread support for release builds

Changes: https://git.openjdk.org/jdk/pull/23339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348800
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/23339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23339/head:pull/23339

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

From shade at openjdk.org  Tue Jan 28 19:45:56 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Jan 2025 19:45:56 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239
In-Reply-To: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
Message-ID: <5dCxe-876yJn9769MjaBzFKFUtRMAw17Ca3tPuhWpWY=.68577f1a-abf6-42ed-a364-4f012583d0d7@github.com>

On Tue, 28 Jan 2025 19:14:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
> 
>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
> 
> But is conditionally included in VMStructs:
> 
>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
> 
> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
> 
>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
> 
> The fix is to not add it to the mapping table if it is not present in the database.
> 
> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.

Looks fine, but I have a minor suggestion:

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 161:

> 159:         /* Only add DeoptimizeObjectsALotThread if it is actually present in the type database. */
> 160:         try {
> 161:             db.lookupType("DeoptimizeObjectsALotThread");

I see there is `public Type lookupType(String cTypeName, boolean throwException);`, so this might be more accurately, without over-catching the exceptions:


  if (db.lookupType("DeoptimizeObjectsALotThread", false) != null) {
     virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
  }


?

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

PR Review: https://git.openjdk.org/jdk/pull/23339#pullrequestreview-2579255107
PR Review Comment: https://git.openjdk.org/jdk/pull/23339#discussion_r1932761452

From kemperw at amazon.com  Tue Jan 28 19:53:46 2025
From: kemperw at amazon.com (Kemper, William)
Date: Tue, 28 Jan 2025 19:53:46 +0000
Subject: Proposal to change the behavior of the timestamp place holder (%t) in
 log file paths
Message-ID: <0b5128abb575460490177c217ee6a4cc@amazon.com>

The timestamp place holder in a log filename currently expands to the startup time of the JVM. When the log is rotated, the filename containing this timestamp is suffixed with a file number. My colleagues had expected the placeholder to be evaluated when the current log file is rotated. They expected the name of each rotated file to indicate the time the file was created. I think this expectation is not unreasonable, so I wanted to discuss the possibility of changing how/when the timestamp placeholder is evaluated. If there is any appetite for a change like this, I am willing to do the work. I would prefer to sort out the details before coding anything, rather than discussing them in a surprise pull request.


Thank you for reading,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250128/8347180d/attachment-0001.htm>

From cjplummer at openjdk.org  Tue Jan 28 20:14:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Jan 2025 20:14:05 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
Message-ID: <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>

> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
> 
>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
> 
> But is conditionally included in VMStructs:
> 
>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
> 
> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
> 
>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
> 
> The fix is to not add it to the mapping table if it is not present in the database.
> 
> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  use lookupType() api that does not throw an exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23339/files
  - new: https://git.openjdk.org/jdk/pull/23339/files/10e03d38..561cd45a

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

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

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

From shade at openjdk.org  Tue Jan 28 20:14:05 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 28 Jan 2025 20:14:05 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
 <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
Message-ID: <U6DarRNUO1sOx4ww3mS0bH8ouvjx69AGNcexfmPh8_c=.0535c3cb-3fe9-46e1-9a02-5e97e16eb9d1@github.com>

On Tue, 28 Jan 2025 20:11:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
>> 
>>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
>> 
>> But is conditionally included in VMStructs:
>> 
>>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
>> 
>> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
>> 
>>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
>> 
>> The fix is to not add it to the mapping table if it is not present in the database.
>> 
>> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use lookupType() api that does not throw an exception.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23339#pullrequestreview-2579316302

From cjplummer at openjdk.org  Tue Jan 28 20:14:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Jan 2025 20:14:05 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <5dCxe-876yJn9769MjaBzFKFUtRMAw17Ca3tPuhWpWY=.68577f1a-abf6-42ed-a364-4f012583d0d7@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
 <5dCxe-876yJn9769MjaBzFKFUtRMAw17Ca3tPuhWpWY=.68577f1a-abf6-42ed-a364-4f012583d0d7@github.com>
Message-ID: <QfXFxjP9p66hV5qruymWyxk3gx4FLO8_MZZKIgru3FU=.be70fff1-5293-4515-9f1d-f7ac77ec49cf@github.com>

On Tue, 28 Jan 2025 19:42:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use lookupType() api that does not throw an exception.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 161:
> 
>> 159:         /* Only add DeoptimizeObjectsALotThread if it is actually present in the type database. */
>> 160:         try {
>> 161:             db.lookupType("DeoptimizeObjectsALotThread");
> 
> I see there is `public Type lookupType(String cTypeName, boolean throwException);`, so this might be more accurately, without over-catching the exceptions:
> 
> 
>   if (db.lookupType("DeoptimizeObjectsALotThread", false) != null) {
>      virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
>   }
> 
> 
> ?

Good idea. I've updated to do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23339#discussion_r1932797898

From prr at openjdk.org  Tue Jan 28 20:16:47 2025
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Jan 2025 20:16:47 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
Message-ID: <5rLwREvBwD_4oD3b2to9uvQafxCJ8XFVCXyvjxvMuIY=.198a6e8f-46fa-4b2c-8960-492d7d9f3307@github.com>

On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @serialData text to CSR-approved version

Approving the datatransfer portion

.. at least ...

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2579320786
PR Comment: https://git.openjdk.org/jdk/pull/22980#issuecomment-2619967593

From kevinw at openjdk.org  Tue Jan 28 20:33:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Jan 2025 20:33:48 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
 <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
Message-ID: <SpyqqRa_RK7RYVeH8KESkwzyVpGncmPfoFD1Gz0Kjf0=.05d383ce-d2be-4dd1-ad2b-31d0ff067624@github.com>

On Tue, 28 Jan 2025 20:14:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
>> 
>>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
>> 
>> But is conditionally included in VMStructs:
>> 
>>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
>> 
>> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
>> 
>>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
>> 
>> The fix is to not add it to the mapping table if it is not present in the database.
>> 
>> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use lookupType() api that does not throw an exception.

Yes looks good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23339#pullrequestreview-2579353808

From lmesnik at openjdk.org  Tue Jan 28 20:56:50 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Jan 2025 20:56:50 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
 <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
Message-ID: <EfhqkjlTdkl1lXng30cV3HOrfL2KJe1y_r6Fr5nsbTs=.334bbbb9-b48e-484f-a88b-332f8b3042fe@github.com>

On Tue, 28 Jan 2025 20:14:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
>> 
>>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
>> 
>> But is conditionally included in VMStructs:
>> 
>>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
>> 
>> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
>> 
>>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
>> 
>> The fix is to not add it to the mapping table if it is not present in the database.
>> 
>> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use lookupType() api that does not throw an exception.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23339#pullrequestreview-2579393803

From cjplummer at openjdk.org  Tue Jan 28 23:32:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Jan 2025 23:32:50 GMT
Subject: RFR: 8348800: Many serviceability/sa tests failing after
 JDK-8348239 [v2]
In-Reply-To: <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
 <dRu9AQnl09MF7Jd4A3LIaZEzQEh15KnzHYCNsic86fA=.04eaf80d-c697-4f58-a36d-e9d617db8d54@github.com>
Message-ID: <nbvfWireJaR2zfqWe4ax2Lnq7GE001vUhaXc4wnKkq8=.a0e0065a-b5a1-4121-9361-ea239aa9b37b@github.com>

On Tue, 28 Jan 2025 20:14:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
>> 
>>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
>> 
>> But is conditionally included in VMStructs:
>> 
>>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
>> 
>> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
>> 
>>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
>> 
>> The fix is to not add it to the mapping table if it is not present in the database.
>> 
>> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use lookupType() api that does not throw an exception.

Thanks Aleksey, Kevin, and Leonid.

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

PR Comment: https://git.openjdk.org/jdk/pull/23339#issuecomment-2620265116

From cjplummer at openjdk.org  Tue Jan 28 23:32:51 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 28 Jan 2025 23:32:51 GMT
Subject: Integrated: 8348800: Many serviceability/sa tests failing after
 JDK-8348239
In-Reply-To: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
References: <rOzkXNGCfrxQEODT4BP97f2o3-ptMe6MtaCcCbdmEs4=.76a9b98e-16d8-4f8f-a7fb-a5dadc111240@github.com>
Message-ID: <ksHpMze8-cu1epn0KC_OOebDsROeBxTcx4P43R93NM8=.06124120-7341-4820-ae18-af6ecbad00ca@github.com>

On Tue, 28 Jan 2025 19:14:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> DeoptimizeObjectsALotThread was being unconditionally added to the mapping table:
> 
>        virtualConstructor.addMapping("DeoptimizeObjectsALotThread", DeoptimizeObjectsALotThread.class);
> 
> But is conditionally included in VMStructs:
> 
>          DEBUG_ONLY(COMPILER2_OR_JVMCI_PRESENT( \
>           declare_type(DeoptimizeObjectsALotThread, JavaThread))) \ 
> 
> There is code that iterates over all the mapping table entries and calls db.lookupType() on each. This results in a RuntimeException if the type is not present in the type database:
> 
>  Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database 
> 
> The fix is to not add it to the mapping table if it is not present in the database.
> 
> Testing is in progresses. I did test locally with a debug build using TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure the original DeoptimizeObjectsALotThread issue is still fixed, and then tested a release build without TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot to make sure this new issue did not reproduce.

This pull request has now been integrated.

Changeset: 98a93e11
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/98a93e115137a305aed6b7dbf1d4a7d5906fe77c
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8348800: Many serviceability/sa tests failing after JDK-8348239

Reviewed-by: shade, kevinw, lmesnik

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

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

From cjplummer at openjdk.org  Wed Jan 29 02:40:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Jan 2025 02:40:48 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v3]
In-Reply-To: <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
Message-ID: <MUBbXMjcAIs19wachTwpXSA3R6skINGPeQUP1bJoBWk=.f6c861d3-8105-495d-af39-c2bad7a99494@github.com>

On Thu, 23 Jan 2025 09:07:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check doSleep in launch

It's functionally correct but could use some comments.

test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 56:

> 54:     static boolean doSleep = true; // By default do a short sleep when app starts up
> 55: 
> 56:     public static boolean launch(String expectedMessage, List<String> toolArgs, boolean allowRetry)

You should add a comment explaining the return value like we have for printStackTraces().

test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 105:

> 103: 
> 104:         boolean res = launch(expectedMessage, Arrays.asList(toolArgs), true);
> 105:         if (!res && !doSleep) {

You should explain why we allow a retry here, and only for !doSleep, like we do in printStackTraces(). Note the doSleep reason is a bit different here. It is because the sleep allows the debuggee to stabilize, making it very unlikely that jmap will fail.

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23213#pullrequestreview-2579815041
PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1933131474
PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1933133351

From cjplummer at openjdk.org  Wed Jan 29 02:42:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Jan 2025 02:42:55 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v3]
In-Reply-To: <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
 <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
Message-ID: <DClY1dpbC_rBVdlQH-bbBn0e9GjwTDjtyTtp93OdtNg=.65fee8b4-cfd4-48d5-9123-e62d6c9c61c2@github.com>

On Tue, 28 Jan 2025 14:08:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
>> 
>> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
>> 
>> Testing:
>> - Ran mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct typo in log messages; refactor error checking/reporting

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23314#pullrequestreview-2579819532

From kevinw at openjdk.org  Wed Jan 29 08:45:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 29 Jan 2025 08:45:10 GMT
Subject: Integrated: 8347985: Deprecate java.management Permission classes for
 removal
In-Reply-To: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
References: <7qvKHcd6J3ckrMUSJ1-HWWNoAQx41o3TSdrdXzGgW_o=.64e3aa06-6d54-4aca-9097-0e085f0f8fbb@github.com>
Message-ID: <bEpb220xO9v0mz8euZMAVcOrketh6ElFC1aElzwXP1o=.086c59c5-d75a-4e86-a71a-820c2d9baf4e@github.com>

On Fri, 17 Jan 2025 17:27:54 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.  This change is for those in the java.management module.

This pull request has now been integrated.

Changeset: 69ec4534
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69ec45348a89eb93794f04cf0d5a61377b90f156
Stats:     31 lines in 5 files changed: 25 ins; 0 del; 6 mod

8347985: Deprecate java.management Permission classes for removal

Reviewed-by: sspitsyn, rriggs

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

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

From kevin.walls at oracle.com  Wed Jan 29 09:24:52 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Wed, 29 Jan 2025 09:24:52 +0000
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <0b5128abb575460490177c217ee6a4cc@amazon.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
Message-ID: <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>

Hi,

Just checking, but are they sure that's what they want? 8-)

This relates to files from unified logging, like java -Xlog:gc*:file%t.out ...creates:  file2025-01-28_21-43-53.out and -Xlog:help says, "If the filename contains %p, %t and/or %hn, they will expand to the JVM's PID, startup timestamp and host name, respectively."

(Administratively, I think unified logging is under the runtime group, cc'd.)

Using the JVM start time, across all log files, identifies the set of files that come from the same process.  They will generally sort together when viewing a directory.  If a single file gets copied around, it can still be traced back in its group.   When there are multiple sets of logs in the same directory, the sets should still sort together.   I see the filename purpose as to identify the log, or set of logs.


Using a new timestamp for each file, the filenames do not identify the files as being part of the same run.  They may sort together, but may not if another log series is in the same directory, and once separated it's hard to regroup them.

Using the pid as well will help, but if we see a lot of low-numbered PIDs then this won't be unique. (With the current startup timestamp, you will probably use %p for pid in the file as well, in case JVMs start at the same moment.)

Thanks
Kevin



From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of Kemper, William
Sent: Tuesday, January 28, 2025 7:54 PM
To: serviceability-dev at openjdk.org
Subject: Proposal to change the behavior of the timestamp place holder (%t) in log file paths


The timestamp place holder in a log filename currently expands to the startup time of the JVM. When the log is rotated, the filename containing this timestamp is suffixed with a file number. My colleagues had expected the placeholder to be evaluated when the current log file is rotated. They expected the name of each rotated file to indicate the time the file was created. I think this expectation is not unreasonable, so I wanted to discuss the possibility of changing how/when the timestamp placeholder is evaluated. If there is any appetite for a change like this, I am willing to do the work. I would prefer to sort out the details before coding anything, rather than discussing them in a surprise pull request.



Thank you for reading,

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250129/2ff46652/attachment-0001.htm>

From jsjolen at openjdk.org  Wed Jan 29 10:25:45 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 29 Jan 2025 10:25:45 GMT
Subject: RFR: 8348567: [ASAN] Memory access partially overflows by
 NativeCallStack
In-Reply-To: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
References: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
Message-ID: <cyGmagPLffwd375quHjjX3IdunCoQ22bRsDqKxNV-vc=.709aee38-0383-405c-99c3-5de161f46a95@github.com>

On Fri, 24 Jan 2025 09:53:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes' testcase 
> locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file when call `NativeCallStack::NativeCallStack` function. Before this PR, 'CollisionsReceiveDifferentIndexes' test allocate 4 type variable `i` and then pass the address `&i`, but in 'NativeCallStack' function read the pointer as 8 types, so the AddressSanitizer report "Memory access partially overflows variable i". This PR change the variable `i` to `size_t` to avoid this undefined behaviour.
> Change has been verified locally, test-fix only, no risk.
> 
> Below code snippet can reproduce the same issue:
> 
> 
> #include <stdio.h>
> typedef unsigned char u_char;
> typedef u_char*       address;
> int main()
> {
>   int i = 0;
>   address* pc = (address*)(&i);
>   address _stack = pc[0];
>   printf("_stack = %p\n", _stack);
>   return 0;
> }
> 
> 
> Reproduce command:
> 
> clang -g3 -Wall -Wextra -fsanitize=address -fsanitize=leak -fsanitize=undefined partially-overflows.c && ./a.out

Hi,

Thank you for the fix. This is correct. Context to the other reviewers: We just needed *some* unique "addresses", as we know that these aren't going to be dereferenced it didn't matter what the addresses are.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23294#pullrequestreview-2580590360

From mbaesken at openjdk.org  Wed Jan 29 12:46:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Jan 2025 12:46:29 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v4]
In-Reply-To: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
Message-ID: <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>

> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
> 
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
> 
> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23213/files
  - new: https://git.openjdk.org/jdk/pull/23213/files/168f6561..bc6717d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23213&range=02-03

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

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

From mbaesken at openjdk.org  Wed Jan 29 12:46:29 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 29 Jan 2025 12:46:29 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v3]
In-Reply-To: <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <wU28AGA7CuqD_16x87kUhxM0JhIVoLaO9V2kWX9Jx88=.d89611ff-e33c-4986-b815-044901ad65d6@github.com>
Message-ID: <DU8XSIIWTLqWbPBuEYytucKJHU1DxaNQoqjLbokV9_s=.10c38766-85b6-4ecd-966a-7d2d78b2af6c@github.com>

On Thu, 23 Jan 2025 09:07:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check doSleep in launch

Hi Chris, I added comments .

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

PR Comment: https://git.openjdk.org/jdk/pull/23213#issuecomment-2621538470

From cjplummer at openjdk.org  Wed Jan 29 16:18:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 29 Jan 2025 16:18:47 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v4]
In-Reply-To: <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
Message-ID: <a5Goju9ij0jL9c5f28_JCyCO6aLgaRj1JTH8xFP_GOw=.a8c91219-4a40-4f75-bfb8-2b9ff4b052e0@github.com>

On Wed, 29 Jan 2025 12:46:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23213#pullrequestreview-2581556193

From lmesnik at openjdk.org  Wed Jan 29 19:18:49 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Jan 2025 19:18:49 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v3]
In-Reply-To: <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
 <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
Message-ID: <Qx28zhuiGXATmir2Dq5xVqyJoXsaP8LNGdDA32nOWFA=.eeabde18-bac6-4200-b403-cc3cdb864acf@github.com>

On Tue, 28 Jan 2025 14:08:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
>> 
>> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
>> 
>> Testing:
>> - Ran mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct typo in log messages; refactor error checking/reporting

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23314#pullrequestreview-2581991986

From kevinw at openjdk.org  Wed Jan 29 19:33:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 29 Jan 2025 19:33:53 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v4]
In-Reply-To: <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
Message-ID: <zGulKU13YtUv3ZEGQHM1RDqiGbDzrwZzviH129_5SBw=.3b41f2cc-2126-4cf6-8c61-1b3e1cf60c5d@github.com>

On Wed, 29 Jan 2025 12:46:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23213#pullrequestreview-2582033507

From nbenalla at openjdk.org  Wed Jan 29 22:18:27 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Wed, 29 Jan 2025 22:18:27 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API documentation,
 build 33
Message-ID: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>

Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.

- The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.

- Contacted ietf, these are the new links to use.

This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.

Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.

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

Commit messages:
 - - fix broken ietf links

Changes: https://git.openjdk.org/jdk/pull/23351/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23351&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348975
  Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23351.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23351/head:pull/23351

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

From liach at openjdk.org  Wed Jan 29 22:31:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 29 Jan 2025 22:31:45 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
Message-ID: <AfYv0pq3xKbccWZkbgmyOo8rzuMM9k10cE3xn6rPfI4=.2120d72d-23ce-4f4c-85b5-804dca5a34c1@github.com>

On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
> 
> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
> 
> - Contacted ietf, these are the new links to use.
> 
> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
> 
> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.

Looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23351#pullrequestreview-2582510381

From ihse at openjdk.org  Wed Jan 29 23:17:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 29 Jan 2025 23:17:45 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
Message-ID: <VetnEYFBAf27b0JlHaT7cfVU1HrviQ08dlkxz12h96w=.7421ddbb-ad67-42f8-a177-bdfb300ddde7@github.com>

On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
> 
> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
> 
> - Contacted ietf, these are the new links to use.
> 
> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
> 
> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.

make/common/Modules.gmk line 95:

> 93: SPEC_SUBDIRS += share/specs
> 94: 
> 95: MAN_SUBDIRS += share/man windows/man

Hm, normally I'd say you should use `$(TARGET_OS)/man`, but we typically generate docs for all platforms at the same time. So I guess this is okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23351#discussion_r1934785667

From david.holmes at oracle.com  Thu Jan 30 01:56:35 2025
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Jan 2025 11:56:35 +1000
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
Message-ID: <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>

Adding back serviceability-dev

David

On 30/01/2025 11:55 am, David Holmes wrote:
> Plus one to what Kevin says. The current specified behaviour seems to me 
> to be what would be generally desired. If there is a desire for a 
> different kind of timestamp to be used then a proposal to add that would 
> be more appropriate I think. I seem to recall something fairly recent 
> about expanding the notion of "timestamp" that can be used here.
> 
> David
> 
> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>> Hi,
>>
>> Just checking, but are they sure that's what they want? 8-)
>>
>> This relates to files from unified logging, like java - 
>> Xlog:gc*:file%t.out ...creates:? file2025-01-28_21-43-53.out and - 
>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they will 
>> expand to the JVM's PID, startup timestamp and host name, respectively."
>>
>> (Administratively, I think unified logging is under the runtime group, 
>> cc?d.)
>>
>> Using the JVM start time, across all log files, identifies the set of 
>> files that come from the same process.? They will generally sort 
>> together when viewing a directory.? If a single file gets copied 
>> around, it can still be traced back in its group.?? When there are 
>> multiple sets of logs in the same directory, the sets should still 
>> sort together.?? I see the filename purpose as to identify the log, or 
>> set of logs.
>>
>> Using a new timestamp for each file, the filenames do not identify the 
>> files as being part of the same run.? They may sort together, but may 
>> not if another log series is in the same directory, and once separated 
>> it's hard to regroup them.
>>
>> Using the pid as well will help, but if we see a lot of low-numbered 
>> PIDs then this won't be unique. (With the current startup timestamp, 
>> you will probably use %p for pid in the file as well, in case JVMs 
>> start at the same moment.)
>>
>> Thanks
>>
>> Kevin
>>
>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> *On 
>> Behalf Of *Kemper, William
>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>> *To:* serviceability-dev at openjdk.org
>> *Subject:* Proposal to change the behavior of the timestamp place 
>> holder (%t) in log file paths
>>
>> The timestamp place holder in a log filename currently expands to the 
>> startup time of the JVM. When the log is rotated, the filename 
>> containing this timestamp is suffixed with a file number. My 
>> colleagues had expected the placeholder to be evaluated when the 
>> current log?file is rotated. They expected the name of each rotated 
>> file to indicate the time the file was created. I think this 
>> expectation is not unreasonable, so I wanted to discuss the 
>> possibility of changing how/when the timestamp placeholder is 
>> evaluated. If there is any appetite for a change like this, I am 
>> willing to do the work. I would prefer to sort out the details before 
>> coding anything, rather than discussing them in a surprise pull request.
>>
>> Thank you for reading,
>>
>> William
>>
> 


From chris.plummer at oracle.com  Thu Jan 30 03:45:49 2025
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 29 Jan 2025 19:45:49 -0800
Subject: Remote debugging should print warning when binding to external
 address
In-Reply-To: <5482a0ac-f56b-4115-8a53-1ea1cdaf8211@vodafonemail.de>
References: <8c38c963-ba6a-4253-9233-d78060ab0014@vodafonemail.de>
 <a3729eb3-6753-4b56-9383-9df8f76af7b2@oracle.com>
 <8f178482-b193-441c-96bb-73525f1dc3b4@vodafonemail.de>
 <0da5c8e2-2905-4b28-8c9b-3cbe712b2fe7@oracle.com>
 <5482a0ac-f56b-4115-8a53-1ea1cdaf8211@vodafonemail.de>
Message-ID: <bee135a4-8669-4651-92d8-8eb0562f5282@oracle.com>


On 1/21/25 12:57 PM, some-java-user-99206970363698485155 at vodafonemail.de 
wrote:
>>> It seems I wasn't informed that the report had been created; at 
>>> least I cannot find the confirmation mail for it. Note that I had 
>>> specified a different private contact e-mail address.
>>
>> It's because the bug isn't public. 
> ... but I am the reporter!? It could of course be that there was an 
> attempt to inform me but it did not reach me for whatever reason 
> (please don't mention the e-mail address, I used for reporting, here 
> on this mailing list though).
>
> That is unfortunately exactly what I had been criticizing in 
> https://mail.openjdk.org/pipermail/web-discuss/2022-January/000593.html; 
> as external reporter it can be extremely intransparent what happens to 
> a report.
>
>> Yes, the bug is marked confidential.
> I don't really understand that. Unless I accidentally leaked private 
> information in the report, I think it contains exactly the information 
> I wrote in the original e-mail of this thread. And this is not secret 
> information, it is basically what had been mentioned in the JDK 9 
> release notes originally. It is rather weird to withhold this 
> information from users, especially since malicious actors are long 
> aware of the security issues see for example 
> https://www.alibabacloud.com/blog/analysis-of-jdwpminer-mining-trojan-remote-debugging-with-java-causes-hidden-risks_598002 
> or just search for "jdwp exploit" or similar.
>
> (Aleksei Ivanov I have included you as direct recipient of this mail; 
> but this mail might still be awaiting approval on serviceability-dev@, 
> so in case you respond before that it might be confusing for others.)
>
https://bugs.openjdk.org/browse/JDK-8329414 is no longer confidential. 
You should be able to view it now.

Chris


From dholmes at openjdk.org  Thu Jan 30 05:40:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 30 Jan 2025 05:40:51 GMT
Subject: RFR: 8348567: [ASAN] Memory access partially overflows by
 NativeCallStack
In-Reply-To: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
References: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
Message-ID: <ONClZB3GzDP4IG7ACbluIV25J3JcPOuB8nIQJz_tHcA=.f559b539-efc2-430f-9f44-4b02ad88cb3a@github.com>

On Fri, 24 Jan 2025 09:53:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes' testcase 
> locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file when call `NativeCallStack::NativeCallStack` function. Before this PR, 'CollisionsReceiveDifferentIndexes' test allocate 4 type variable `i` and then pass the address `&i`, but in 'NativeCallStack' function read the pointer as 8 types, so the AddressSanitizer report "Memory access partially overflows variable i". This PR change the variable `i` to `size_t` to avoid this undefined behaviour.
> Change has been verified locally, test-fix only, no risk.
> 
> Below code snippet can reproduce the same issue:
> 
> 
> #include <stdio.h>
> typedef unsigned char u_char;
> typedef u_char*       address;
> int main()
> {
>   int i = 0;
>   address* pc = (address*)(&i);
>   address _stack = pc[0];
>   printf("_stack = %p\n", _stack);
>   return 0;
> }
> 
> 
> Reproduce command:
> 
> clang -g3 -Wall -Wextra -fsanitize=address -fsanitize=leak -fsanitize=undefined partially-overflows.c && ./a.out

Fix makes sense to me. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23294#pullrequestreview-2582954299

From mbaesken at openjdk.org  Thu Jan 30 08:25:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Jan 2025 08:25:51 GMT
Subject: RFR: 8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java
 fails with Unable to deduce type of thread from address [v4]
In-Reply-To: <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
 <QJkKBNKHIaL3WKMzUpweHBonv320jAblKD2Fo0nLb5g=.9bca8298-8448-45af-a1a5-3568ee847685@github.com>
Message-ID: <ZS1d3cw9MObDpKl8UsfpMSwpZeIGenXnuGr13pLUNB8=.4999f0a2-d4aa-467c-948e-e53f151bf4db@github.com>

On Wed, 29 Jan 2025 12:46:29 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We were running into this error :
>> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>> 
>> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
>> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
>> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
>> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
>> ... 11 more
>> 
>> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23213#issuecomment-2623821695

From mbaesken at openjdk.org  Thu Jan 30 08:25:51 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Jan 2025 08:25:51 GMT
Subject: Integrated: 8347779:
 sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce
 type of thread from address
In-Reply-To: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
References: <liCYJJqboW9VXHvMgakHBRflh3FdTPecnqejXIFWY1g=.0c1273c8-468d-4a9a-9528-ee8aa141ca5a@github.com>
Message-ID: <6I8Al0YWUStutxJfpE9y78AhdZcDVa0r2Cvnt2gy0IY=.5cababe1-48d3-4d78-bbda-6541d621b9c6@github.com>

On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
> 
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
> at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
> ... 11 more
> 
> In the discussion in the JBS bug it was found that a retry option in` launch `should be added.

This pull request has now been integrated.

Changeset: 04c24f18
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04c24f18d554a57c537f3a77c5f6d0d03e7fc3d1
Stats:     14 lines in 1 file changed: 11 ins; 0 del; 3 mod

8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address

Reviewed-by: cjplummer, kevinw

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

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

From syan at openjdk.org  Thu Jan 30 08:58:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 Jan 2025 08:58:50 GMT
Subject: Integrated: 8348567: [ASAN] Memory access partially overflows by
 NativeCallStack
In-Reply-To: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
References: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
Message-ID: <CEz4b6Jnqphf4sXpaOfIPYv0Hu83Pp7s3Z3mQatyHFY=.e69c8ada-f55d-4197-9490-d5d50ec01d2e@github.com>

On Fri, 24 Jan 2025 09:53:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes' testcase 
> locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file when call `NativeCallStack::NativeCallStack` function. Before this PR, 'CollisionsReceiveDifferentIndexes' test allocate 4 type variable `i` and then pass the address `&i`, but in 'NativeCallStack' function read the pointer as 8 types, so the AddressSanitizer report "Memory access partially overflows variable i". This PR change the variable `i` to `size_t` to avoid this undefined behaviour.
> Change has been verified locally, test-fix only, no risk.
> 
> Below code snippet can reproduce the same issue:
> 
> 
> #include <stdio.h>
> typedef unsigned char u_char;
> typedef u_char*       address;
> int main()
> {
>   int i = 0;
>   address* pc = (address*)(&i);
>   address _stack = pc[0];
>   printf("_stack = %p\n", _stack);
>   return 0;
> }
> 
> 
> Reproduce command:
> 
> clang -g3 -Wall -Wextra -fsanitize=address -fsanitize=leak -fsanitize=undefined partially-overflows.c && ./a.out

This pull request has now been integrated.

Changeset: bb528d5a
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb528d5ad6f28e9c1bc4e283d40c70489465bd00
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8348567: [ASAN] Memory access partially overflows by NativeCallStack

Reviewed-by: jsjolen, dholmes

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

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

From syan at openjdk.org  Thu Jan 30 08:58:50 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 Jan 2025 08:58:50 GMT
Subject: RFR: 8348567: [ASAN] Memory access partially overflows by
 NativeCallStack
In-Reply-To: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
References: <hTZA7KBXwUQG0AlssFkoFt2OmPC0R6PD2eWP_gOPG7o=.53b62bda-2db4-4d64-946c-2d87c0aefcce@github.com>
Message-ID: <wp8Ui1ZsX805z434VDXKlSnhQw-BCw6_0VwgIOMBYgw=.9d2905eb-f125-433c-b955-665bd2404b2a@github.com>

On Fri, 24 Jan 2025 09:53:43 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes' testcase 
> locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file when call `NativeCallStack::NativeCallStack` function. Before this PR, 'CollisionsReceiveDifferentIndexes' test allocate 4 type variable `i` and then pass the address `&i`, but in 'NativeCallStack' function read the pointer as 8 types, so the AddressSanitizer report "Memory access partially overflows variable i". This PR change the variable `i` to `size_t` to avoid this undefined behaviour.
> Change has been verified locally, test-fix only, no risk.
> 
> Below code snippet can reproduce the same issue:
> 
> 
> #include <stdio.h>
> typedef unsigned char u_char;
> typedef u_char*       address;
> int main()
> {
>   int i = 0;
>   address* pc = (address*)(&i);
>   address _stack = pc[0];
>   printf("_stack = %p\n", _stack);
>   return 0;
> }
> 
> 
> Reproduce command:
> 
> clang -g3 -Wall -Wextra -fsanitize=address -fsanitize=leak -fsanitize=undefined partially-overflows.c && ./a.out

Thanks all for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/23294#issuecomment-2623885264

From sspitsyn at openjdk.org  Thu Jan 30 09:14:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Jan 2025 09:14:53 GMT
Subject: RFR: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support [v3]
In-Reply-To: <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
 <ImGjMcy7mL4PR9_838gqZVTioftyu12QtsSE1GH-Aaw=.4d79ac0e-f99b-4f03-baf8-0b96c29dd8f0@github.com>
Message-ID: <2h8fkdx0X5-_imEYFwe4UCjpO8rjjZhQF4lcBSjGERw=.cb21a8ed-0b01-4409-bef1-98d99d9eb6a3@github.com>

On Tue, 28 Jan 2025 14:08:26 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
>> 
>> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
>> 
>> Testing:
>> - Ran mach5 tiers 1-5
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: correct typo in log messages; refactor error checking/reporting

Chris and Leonid, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/23314#issuecomment-2623918879

From sspitsyn at openjdk.org  Thu Jan 30 09:14:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Jan 2025 09:14:54 GMT
Subject: Integrated: 8300708: Some nsk jvmti tests fail with virtual thread
 wrapper due to jvmti missing some virtual thread support
In-Reply-To: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
References: <FHvKptyZa7z0vLeDDAUejLSGKw3AvGz8lzY9KhnC0-0=.35b8e040-f89c-448b-a1d4-ebc744fd6979@github.com>
Message-ID: <l5P9IXOa7pnBM8r7GwmiWyLKCq-clEsPHjQ5FKYghmE=.317c4930-b63a-4b5b-9e4c-c9ec69daff02@github.com>

On Mon, 27 Jan 2025 11:24:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Some `nsk.jvmti` tests are failed with the `-testThreadFactory:Virtual`, so they are listed in the `test/hotspot/jtreg/ProblemList-Virtual.txt`.
> 
> The fix is to adjust tests expectations regarding tested virtual threads to expect error `JVMTI_ERROR_OPAQUE_FRAME`.
> 
> Testing:
> - Ran mach5 tiers 1-5

This pull request has now been integrated.

Changeset: fb0f2d25
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb0f2d25d218e64a86995478fd3ea10d619834d5
Stats:     213 lines in 5 files changed: 48 ins; 131 del; 34 mod

8300708: Some nsk jvmti tests fail with virtual thread wrapper due to jvmti missing some virtual thread support

Reviewed-by: cjplummer, lmesnik

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

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

From nbenalla at openjdk.org  Thu Jan 30 10:15:05 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 30 Jan 2025 10:15:05 GMT
Subject: RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
Message-ID: <L-PrWMmbwRVtwCCzgGYIpjDCb6VLWMfgZt3W8G_CH2Y=.a8a36c42-77d1-4629-ace7-799762aaa661@github.com>

On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
> 
> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
> 
> - Contacted ietf, these are the new links to use.
> 
> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
> 
> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.

Thanks for the reviews, integrating now in order to backport this ahead of RC.

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

PR Comment: https://git.openjdk.org/jdk/pull/23351#issuecomment-2624053793

From nbenalla at openjdk.org  Thu Jan 30 10:15:06 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 30 Jan 2025 10:15:06 GMT
Subject: Integrated: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
References: <qJyW0VoLge6V4jHud4SATgydUvoI_3kfMGpi-4GGoBk=.6ff7e29f-8986-4991-a963-37eb50e4db37@github.com>
Message-ID: <kDSftyNKSGkibSt54v9ojO58K05iV3J_4iM90Fx39tA=.c473832b-4c89-4770-8361-34896aedc852@github.com>

On Wed, 29 Jan 2025 16:03:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Two groups of broken links appeared in the latest JDK docs, broken links to man pages and broken ietf links.
> 
> - The windows tools markdown files were not being converted to HTML because they were placed under `windows/man` rather than `share/man`, I've updated `Modules.gmk` to pick up their location.
> 
> - Contacted ietf, these are the new links to use.
> 
> This patch needs to be backported to JDK 24 as the windows tools man pages are not generated there either.
> 
> Note: the change to `ExtLinksJdk.txt` is because we partly use it to check external links, so it needs to be updated alongside the docs.

This pull request has now been integrated.

Changeset: 22069ff4
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef
Stats:     15 lines in 7 files changed: 0 ins; 1 del; 14 mod

8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33

Reviewed-by: liach

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

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

From mbaesken at openjdk.org  Thu Jan 30 10:28:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 30 Jan 2025 10:28:42 GMT
Subject: RFR: 8349039: Adjust exception No type named <ThreadType> in database
Message-ID: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>

We should the exception message from
Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
to
Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" present in type database

(like we have in some other exceptions in the same class)

error was (from [JDK-8348800](https://bugs.openjdk.org/browse/JDK-8348800)) :
serviceability/sa/CDSJMapClstats.java

at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:320)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:216)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:116)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:128)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:95)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:86)
at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:137)
at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:75)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)

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

Commit messages:
 - JDK-8349039

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

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

From nbenalla at openjdk.org  Thu Jan 30 10:48:23 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 30 Jan 2025 10:48:23 GMT
Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
Message-ID: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>

Hi all,

This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang.

Thanks!

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

Commit messages:
 - Backport 22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef

Changes: https://git.openjdk.org/jdk/pull/23366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348975
  Stats: 15 lines in 7 files changed: 0 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/23366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23366/head:pull/23366

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

From ayang at openjdk.org  Thu Jan 30 12:18:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Jan 2025 12:18:55 GMT
Subject: RFR: 8192647: GClocker induced GCs can starve threads requiring memory
 leading to OOME
Message-ID: <8Vqsu8qf5wAN8pZF-8zu8zNhryQa42EZux3nMRChX5k=.63c53ac1-ca69-4a45-a924-9a454e24ea3f@github.com>

Here is an attempt to simplify GCLocker implementation for Serial and Parallel.

GCLocker prevents GC when Java threads are in a critical region (i.e., calling JNI critical APIs). JDK-7129164 introduces an optimization that updates a shared variable (used to track the number of threads in the critical region) only if there is a pending GC request. However, this also means that after reaching a GC safepoint, we may discover that GCLocker is active, preventing a GC cycle from being invoked. The inability to perform GC at a safepoint adds complexity -- for example, a caller must retry allocation if the request fails due to GC being inhibited by GCLocker.

The proposed patch uses a readers-writer lock to ensure that all Java threads exit the critical region before reaching a GC safepoint. This guarantees that once inside the safepoint, we can successfully invoke a GC cycle. The approach takes inspiration from `ZJNICritical`, but some regressions were observed in j2dbench (on Windows) and the micro-benchmark in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, instead of relying on atomic operations on a global variable when entering or leaving the critical region, this PR uses an existing thread-local variable with a store-load barrier for synchronization.

Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress.

Test: tier1-8

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

Commit messages:
 - gclocker

Changes: https://git.openjdk.org/jdk/pull/23367/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8192647
  Stats: 936 lines in 37 files changed: 36 ins; 804 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/23367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367

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

From kevinw at openjdk.org  Thu Jan 30 14:30:46 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 30 Jan 2025 14:30:46 GMT
Subject: RFR: 8349039: Adjust exception No type named <ThreadType> in
 database
In-Reply-To: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
References: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
Message-ID: <B-i5ySE12eRLbeq2bE-z3PISahJHQ_KJvwaaFsKi2ok=.6d0c595a-d55b-472f-bcbb-bff39712cb2a@github.com>

On Thu, 30 Jan 2025 10:22:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should the exception message from
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> to
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" present in type database
> 
> (like we have in some other exceptions in the same class)
> 
> error was (from [JDK-8348800](https://bugs.openjdk.org/browse/JDK-8348800)) :
> serviceability/sa/CDSJMapClstats.java
> 
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:320)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:116)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:128)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:95)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:86)
> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:137)
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:75)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)

Making one exception message phrased like the two other similar examples in the same file.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23365#pullrequestreview-2584064590

From liach at openjdk.org  Thu Jan 30 15:05:49 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 30 Jan 2025 15:05:49 GMT
Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
References: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
Message-ID: <JXZjtWky0IZ4RdiBH7j-qYb0O_Q4aYF0K7zeKj3o6c0=.2a0a1f9d-2f76-43a8-b66d-650aa9023e07@github.com>

On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang.
> 
> Thanks!

Looks good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23366#pullrequestreview-2584160685

From larry.cable at oracle.com  Thu Jan 30 17:14:53 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 30 Jan 2025 09:14:53 -0800
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
 <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>
Message-ID: <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>




On 1/29/25 5:56 PM, David Holmes wrote:
> Adding back serviceability-dev
>
> David
>
> On 30/01/2025 11:55 am, David Holmes wrote:
>> Plus one to what Kevin says. The current specified behaviour seems to 
>> me to be what would be generally desired. If there is a desire for a 
>> different kind of timestamp to be used then a proposal to add that 
>> would be more appropriate I think. I seem to recall something fairly 
>> recent about expanding the notion of "timestamp" that can be used here.

+2 for Kevin and David's observations; changing the timestamp from JVM 
start time to create time, removes valuable and
otherwise unobtainable (correlation) metadata from the logfile names, 
file creation and modification time is available from the
underlying O.S filesystem if needed.

Rgds

- Larry

>>
>> David
>>
>> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>>> Hi,
>>>
>>> Just checking, but are they sure that's what they want? 8-)
>>>
>>> This relates to files from unified logging, like java - 
>>> Xlog:gc*:file%t.out ...creates:? file2025-01-28_21-43-53.out and - 
>>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they 
>>> will expand to the JVM's PID, startup timestamp and host name, 
>>> respectively."
>>>
>>> (Administratively, I think unified logging is under the runtime 
>>> group, cc?d.)
>>>
>>> Using the JVM start time, across all log files, identifies the set 
>>> of files that come from the same process.? They will generally sort 
>>> together when viewing a directory.? If a single file gets copied 
>>> around, it can still be traced back in its group.?? When there are 
>>> multiple sets of logs in the same directory, the sets should still 
>>> sort together.?? I see the filename purpose as to identify the log, 
>>> or set of logs.
>>>
>>> Using a new timestamp for each file, the filenames do not identify 
>>> the files as being part of the same run.? They may sort together, 
>>> but may not if another log series is in the same directory, and once 
>>> separated it's hard to regroup them.
>>>
>>> Using the pid as well will help, but if we see a lot of low-numbered 
>>> PIDs then this won't be unique. (With the current startup timestamp, 
>>> you will probably use %p for pid in the file as well, in case JVMs 
>>> start at the same moment.)
>>>
>>> Thanks
>>>
>>> Kevin
>>>
>>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> *On 
>>> Behalf Of *Kemper, William
>>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>>> *To:* serviceability-dev at openjdk.org
>>> *Subject:* Proposal to change the behavior of the timestamp place 
>>> holder (%t) in log file paths
>>>
>>> The timestamp place holder in a log filename currently expands to 
>>> the startup time of the JVM. When the log is rotated, the filename 
>>> containing this timestamp is suffixed with a file number. My 
>>> colleagues had expected the placeholder to be evaluated when the 
>>> current log?file is rotated. They expected the name of each rotated 
>>> file to indicate the time the file was created. I think this 
>>> expectation is not unreasonable, so I wanted to discuss the 
>>> possibility of changing how/when the timestamp placeholder is 
>>> evaluated. If there is any appetite for a change like this, I am 
>>> willing to do the work. I would prefer to sort out the details 
>>> before coding anything, rather than discussing them in a surprise 
>>> pull request.
>>>
>>> Thank you for reading,
>>>
>>> William
>>>
>>
>


From kemperw at amazon.com  Thu Jan 30 17:42:48 2025
From: kemperw at amazon.com (Kemper, William)
Date: Thu, 30 Jan 2025 17:42:48 +0000
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
 <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>,
 <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>
Message-ID: <1343e908588646dba4795a3a0de6be2c@amazon.com>

Thank you all for your comments. We've gotten by using the pid (%p) as a means of grouping log files from a process. The log messages themselves include the uptime, so having the start time of the JVM in the file name has not been useful (and it would be trivial to add in from startup scripts). I take your points about using the modification time of the files and will consider this.

________________________________
From: Laurence Cable <larry.cable at oracle.com>
Sent: Thursday, January 30, 2025 9:14:53 AM
To: Kemper, William; serviceability-dev; David Holmes; hotspot-runtime-dev at openjdk.org
Subject: RE: [EXTERNAL] Proposal to change the behavior of the timestamp place holder (%t) in log file paths

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



On 1/29/25 5:56 PM, David Holmes wrote:
> Adding back serviceability-dev
>
> David
>
> On 30/01/2025 11:55 am, David Holmes wrote:
>> Plus one to what Kevin says. The current specified behaviour seems to
>> me to be what would be generally desired. If there is a desire for a
>> different kind of timestamp to be used then a proposal to add that
>> would be more appropriate I think. I seem to recall something fairly
>> recent about expanding the notion of "timestamp" that can be used here.

+2 for Kevin and David's observations; changing the timestamp from JVM
start time to create time, removes valuable and
otherwise unobtainable (correlation) metadata from the logfile names,
file creation and modification time is available from the
underlying O.S filesystem if needed.

Rgds

- Larry

>>
>> David
>>
>> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>>> Hi,
>>>
>>> Just checking, but are they sure that's what they want? 8-)
>>>
>>> This relates to files from unified logging, like java -
>>> Xlog:gc*:file%t.out ...creates:  file2025-01-28_21-43-53.out and -
>>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they
>>> will expand to the JVM's PID, startup timestamp and host name,
>>> respectively."
>>>
>>> (Administratively, I think unified logging is under the runtime
>>> group, cc?d.)
>>>
>>> Using the JVM start time, across all log files, identifies the set
>>> of files that come from the same process.  They will generally sort
>>> together when viewing a directory.  If a single file gets copied
>>> around, it can still be traced back in its group.   When there are
>>> multiple sets of logs in the same directory, the sets should still
>>> sort together.   I see the filename purpose as to identify the log,
>>> or set of logs.
>>>
>>> Using a new timestamp for each file, the filenames do not identify
>>> the files as being part of the same run.  They may sort together,
>>> but may not if another log series is in the same directory, and once
>>> separated it's hard to regroup them.
>>>
>>> Using the pid as well will help, but if we see a lot of low-numbered
>>> PIDs then this won't be unique. (With the current startup timestamp,
>>> you will probably use %p for pid in the file as well, in case JVMs
>>> start at the same moment.)
>>>
>>> Thanks
>>>
>>> Kevin
>>>
>>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> *On
>>> Behalf Of *Kemper, William
>>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>>> *To:* serviceability-dev at openjdk.org
>>> *Subject:* Proposal to change the behavior of the timestamp place
>>> holder (%t) in log file paths
>>>
>>> The timestamp place holder in a log filename currently expands to
>>> the startup time of the JVM. When the log is rotated, the filename
>>> containing this timestamp is suffixed with a file number. My
>>> colleagues had expected the placeholder to be evaluated when the
>>> current log file is rotated. They expected the name of each rotated
>>> file to indicate the time the file was created. I think this
>>> expectation is not unreasonable, so I wanted to discuss the
>>> possibility of changing how/when the timestamp placeholder is
>>> evaluated. If there is any appetite for a change like this, I am
>>> willing to do the work. I would prefer to sort out the details
>>> before coding anything, rather than discussing them in a surprise
>>> pull request.
>>>
>>> Thank you for reading,
>>>
>>> William
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250130/94b94d1a/attachment.htm>

From larry.cable at oracle.com  Thu Jan 30 18:03:16 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Thu, 30 Jan 2025 10:03:16 -0800
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <1343e908588646dba4795a3a0de6be2c@amazon.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
 <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>
 <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>
 <1343e908588646dba4795a3a0de6be2c@amazon.com>
Message-ID: <67878131-7ddf-4354-a057-fdafd419afee@oracle.com>




On 1/30/25 9:42 AM, Kemper, William wrote:
>
> Thank you all for your comments. We've gotten by using the pid (%p) as 
> a means of grouping log files from a process. The log messages 
> themselves include the uptime, so having the start time of the JVM in 
> the file name has not been useful (and it would be trivial to add in 
> from?startup scripts). I take your points about using the modification 
> time of the files and will consider this.
>

is not also the case that "trivial to add in from startup scripts" also 
true for creation time?

perhaps propose a new substitution variable instead of redefining the 
existing one?

e.g: %c

- Larry

> ------------------------------------------------------------------------
> *From:* Laurence Cable <larry.cable at oracle.com>
> *Sent:* Thursday, January 30, 2025 9:14:53 AM
> *To:* Kemper, William; serviceability-dev; David Holmes; 
> hotspot-runtime-dev at openjdk.org
> *Subject:* RE: [EXTERNAL] Proposal to change the behavior of the 
> timestamp place holder (%t) in log file paths
> CAUTION: This email originated from outside of the organization. Do 
> not click links or open attachments unless you can confirm the sender 
> and know the content is safe.
>
>
>
> On 1/29/25 5:56 PM, David Holmes wrote:
> > Adding back serviceability-dev
> >
> > David
> >
> > On 30/01/2025 11:55 am, David Holmes wrote:
> >> Plus one to what Kevin says. The current specified behaviour seems to
> >> me to be what would be generally desired. If there is a desire for a
> >> different kind of timestamp to be used then a proposal to add that
> >> would be more appropriate I think. I seem to recall something fairly
> >> recent about expanding the notion of "timestamp" that can be used here.
>
> +2 for Kevin and David's observations; changing the timestamp from JVM
> start time to create time, removes valuable and
> otherwise unobtainable (correlation) metadata from the logfile names,
> file creation and modification time is available from the
> underlying O.S filesystem if needed.
>
> Rgds
>
> - Larry
>
> >>
> >> David
> >>
> >> On 29/01/2025 7:24 pm, Kevin Walls wrote:
> >>> Hi,
> >>>
> >>> Just checking, but are they sure that's what they want? 8-)
> >>>
> >>> This relates to files from unified logging, like java -
> >>> Xlog:gc*:file%t.out ...creates: file2025-01-28_21-43-53.out and -
> >>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they
> >>> will expand to the JVM's PID, startup timestamp and host name,
> >>> respectively."
> >>>
> >>> (Administratively, I think unified logging is under the runtime
> >>> group, cc?d.)
> >>>
> >>> Using the JVM start time, across all log files, identifies the set
> >>> of files that come from the same process.? They will generally sort
> >>> together when viewing a directory.? If a single file gets copied
> >>> around, it can still be traced back in its group.?? When there are
> >>> multiple sets of logs in the same directory, the sets should still
> >>> sort together.?? I see the filename purpose as to identify the log,
> >>> or set of logs.
> >>>
> >>> Using a new timestamp for each file, the filenames do not identify
> >>> the files as being part of the same run.? They may sort together,
> >>> but may not if another log series is in the same directory, and once
> >>> separated it's hard to regroup them.
> >>>
> >>> Using the pid as well will help, but if we see a lot of low-numbered
> >>> PIDs then this won't be unique. (With the current startup timestamp,
> >>> you will probably use %p for pid in the file as well, in case JVMs
> >>> start at the same moment.)
> >>>
> >>> Thanks
> >>>
> >>> Kevin
> >>>
> >>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> *On
> >>> Behalf Of *Kemper, William
> >>> *Sent:* Tuesday, January 28, 2025 7:54 PM
> >>> *To:* serviceability-dev at openjdk.org
> >>> *Subject:* Proposal to change the behavior of the timestamp place
> >>> holder (%t) in log file paths
> >>>
> >>> The timestamp place holder in a log filename currently expands to
> >>> the startup time of the JVM. When the log is rotated, the filename
> >>> containing this timestamp is suffixed with a file number. My
> >>> colleagues had expected the placeholder to be evaluated when the
> >>> current log file is rotated. They expected the name of each rotated
> >>> file to indicate the time the file was created. I think this
> >>> expectation is not unreasonable, so I wanted to discuss the
> >>> possibility of changing how/when the timestamp placeholder is
> >>> evaluated. If there is any appetite for a change like this, I am
> >>> willing to do the work. I would prefer to sort out the details
> >>> before coding anything, rather than discussing them in a surprise
> >>> pull request.
> >>>
> >>> Thank you for reading,
> >>>
> >>> William
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250130/ab9607b4/attachment-0001.htm>

From cjplummer at openjdk.org  Thu Jan 30 18:44:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 30 Jan 2025 18:44:44 GMT
Subject: RFR: 8349039: Adjust exception No type named <ThreadType> in
 database
In-Reply-To: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
References: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
Message-ID: <zR_JC0lJubCyZYnthV172nMorJW8sqQMSd2pFCqF9D0=.70ea21ec-b82a-42f8-9602-8a5aca16ef55@github.com>

On Thu, 30 Jan 2025 10:22:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should the exception message from
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> to
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" present in type database
> 
> (like we have in some other exceptions in the same class)
> 
> error was (from [JDK-8348800](https://bugs.openjdk.org/browse/JDK-8348800)) :
> serviceability/sa/CDSJMapClstats.java
> 
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:320)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:116)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:128)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:95)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:86)
> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:137)
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:75)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)

Marked as reviewed by cjplummer (Reviewer).

Looks good. Also is trivial.

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

PR Review: https://git.openjdk.org/jdk/pull/23365#pullrequestreview-2584749505
PR Comment: https://git.openjdk.org/jdk/pull/23365#issuecomment-2625293227

From nbenalla at openjdk.org  Fri Jan 31 01:17:54 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 31 Jan 2025 01:17:54 GMT
Subject: [jdk24] RFR: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
References: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
Message-ID: <hmqqWbXkLZFp7YM370Gjh1wFS1Dyze3ySyKQa2aeokQ=.d6cf7560-8a71-4861-91d1-594f2ef448a7@github.com>

On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang.
> 
> Thanks!

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/23366#issuecomment-2626070036

From nbenalla at openjdk.org  Fri Jan 31 01:17:55 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 31 Jan 2025 01:17:55 GMT
Subject: [jdk24] Integrated: 8348975: Broken links in the JDK 24 JavaDoc API
 documentation, build 33
In-Reply-To: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
References: <sY9H1gq-QcRoRHzN3Jeoryy68WvOdIdTu4J2ZM5Id6U=.bd80001e-0f96-40c6-b1e6-25b8b7b26dca@github.com>
Message-ID: <6Q4dET5Tg8StYXpkRgqB2QITdEP_U3ItS28pDVLYnEw=.8d6b3e9e-5665-4e27-86e0-ebfb9b998e84@github.com>

On Thu, 30 Jan 2025 10:42:43 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [22069ff4](https://github.com/openjdk/jdk/commit/22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Nizar Benalla on 30 Jan 2025 and was reviewed by Chen Liang.
> 
> Thanks!

This pull request has now been integrated.

Changeset: ec00b6b7
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec00b6b7aceafd59eaec6149acec973eed561e82
Stats:     15 lines in 7 files changed: 0 ins; 1 del; 14 mod

8348975: Broken links in the JDK 24 JavaDoc API documentation, build 33

Reviewed-by: liach
Backport-of: 22069ff42b7e5c3058415ef9b6e0b50b9d2c16ef

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

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

From nbenalla at openjdk.org  Fri Jan 31 02:08:30 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 31 Jan 2025 02:08:30 GMT
Subject: RFR: 8347123: Add missing @serial tags to other modules [v2]
In-Reply-To: <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
References: <vie8p5lBDverVLrncpBPCrtpX2x6jBN5qijLZ2BkZSY=.a457ede0-ece9-488c-8b03-733cb4b143da@github.com>
 <wj4VAEKMgc-CPtcZH_LZUtt2Z2a3VyUmGZUdnpuwR_A=.92ee1263-2bbe-4a2f-8f52-1d1d86b9b4f5@github.com>
Message-ID: <fz54XOT0N4oBFyyCTff5XwW4l4Y5g99eTqiOmmY4G8s=.a18c8d70-255a-4d34-ac53-e1a28596f067@github.com>

On Fri, 24 Jan 2025 10:58:24 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to mostly add missing `@serial` javadoc tags. This is a sub-task of [JDK-8286931] to allow us to re-enable the javadoc `-serialwarn` option in the JDK doc build, which has been disabled since JDK 19.
>> 
>> [JDK-8286931]: https://bugs.openjdk.org/browse/JDK-8286931
>> 
>> For private and package-private serialized fields that already have a doc comment, the main description is converted to a block tag by prepending `@serial` since these fields do not require a main description. For protected and public serialized fields that require a main description, an empty `@serial` block tag is appended to the doc comment instead. The effect is the same, as the main description is used in `serial-form.html` if the `@serial` tag is missing or empty. For those fields that do not have a doc comment, a doc comment with an empty `@serial` tag is added. 
>> 
>> Apart from missing `@serial` tags, this PR also adds a `@serialData` tag to `java.awt.datatransfer.DataFlavor.writeExternal(ObjectOutput)` that the javadoc `-serialwarn` option complains about. This is the only change in this PR that adds documentation text and causes a change in the generated documentation.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update @serialData text to CSR-approved version

Code changes make sense and the updated text matches the text from the CSR.

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

Marked as reviewed by nbenalla (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22980#pullrequestreview-2585511820

From david.holmes at oracle.com  Fri Jan 31 02:58:11 2025
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 31 Jan 2025 12:58:11 +1000
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <67878131-7ddf-4354-a057-fdafd419afee@oracle.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
 <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>
 <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>
 <1343e908588646dba4795a3a0de6be2c@amazon.com>
 <67878131-7ddf-4354-a057-fdafd419afee@oracle.com>
Message-ID: <9fc8ac63-5b69-4a99-9495-1ec6156bfe2c@oracle.com>

On 31/01/2025 4:03 am, Laurence Cable wrote:
> On 1/30/25 9:42 AM, Kemper, William wrote:
>>
>> Thank you all for your comments. We've gotten by using the pid (%p) as 
>> a means of grouping log files from a process. The log messages 
>> themselves include the uptime, so having the start time of the JVM in 
>> the file name has not been useful (and it would be trivial to add in 
>> from?startup scripts). I take your points about using the modification 
>> time of the files and will consider this.
>>
> 
> is not also the case that "trivial to add in from startup scripts" also 
> true for creation time?
> 
> perhaps propose a new substitution variable instead of redefining the 
> existing one?
> 
> e.g: %c

There has been some recent discussion (which I can't locate) about 
enabling various filename substitutions that match with the different 
Unified Logging timestamp decorators. Also Zhengyu just filed JDK-8349083.

David

> - Larry
> 
>> ------------------------------------------------------------------------
>> *From:* Laurence Cable <larry.cable at oracle.com>
>> *Sent:* Thursday, January 30, 2025 9:14:53 AM
>> *To:* Kemper, William; serviceability-dev; David Holmes; hotspot- 
>> runtime-dev at openjdk.org
>> *Subject:* RE: [EXTERNAL] Proposal to change the behavior of the 
>> timestamp place holder (%t) in log file paths
>> CAUTION: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you can confirm the sender 
>> and know the content is safe.
>>
>>
>>
>> On 1/29/25 5:56 PM, David Holmes wrote:
>> > Adding back serviceability-dev
>> >
>> > David
>> >
>> > On 30/01/2025 11:55 am, David Holmes wrote:
>> >> Plus one to what Kevin says. The current specified behaviour seems to
>> >> me to be what would be generally desired. If there is a desire for a
>> >> different kind of timestamp to be used then a proposal to add that
>> >> would be more appropriate I think. I seem to recall something fairly
>> >> recent about expanding the notion of "timestamp" that can be used here.
>>
>> +2 for Kevin and David's observations; changing the timestamp from JVM
>> start time to create time, removes valuable and
>> otherwise unobtainable (correlation) metadata from the logfile names,
>> file creation and modification time is available from the
>> underlying O.S filesystem if needed.
>>
>> Rgds
>>
>> - Larry
>>
>> >>
>> >> David
>> >>
>> >> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>> >>> Hi,
>> >>>
>> >>> Just checking, but are they sure that's what they want? 8-)
>> >>>
>> >>> This relates to files from unified logging, like java -
>> >>> Xlog:gc*:file%t.out ...creates: file2025-01-28_21-43-53.out and -
>> >>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they
>> >>> will expand to the JVM's PID, startup timestamp and host name,
>> >>> respectively."
>> >>>
>> >>> (Administratively, I think unified logging is under the runtime
>> >>> group, cc?d.)
>> >>>
>> >>> Using the JVM start time, across all log files, identifies the set
>> >>> of files that come from the same process.? They will generally sort
>> >>> together when viewing a directory.? If a single file gets copied
>> >>> around, it can still be traced back in its group.?? When there are
>> >>> multiple sets of logs in the same directory, the sets should still
>> >>> sort together.?? I see the filename purpose as to identify the log,
>> >>> or set of logs.
>> >>>
>> >>> Using a new timestamp for each file, the filenames do not identify
>> >>> the files as being part of the same run.? They may sort together,
>> >>> but may not if another log series is in the same directory, and once
>> >>> separated it's hard to regroup them.
>> >>>
>> >>> Using the pid as well will help, but if we see a lot of low-numbered
>> >>> PIDs then this won't be unique. (With the current startup timestamp,
>> >>> you will probably use %p for pid in the file as well, in case JVMs
>> >>> start at the same moment.)
>> >>>
>> >>> Thanks
>> >>>
>> >>> Kevin
>> >>>
>> >>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> *On
>> >>> Behalf Of *Kemper, William
>> >>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>> >>> *To:* serviceability-dev at openjdk.org
>> >>> *Subject:* Proposal to change the behavior of the timestamp place
>> >>> holder (%t) in log file paths
>> >>>
>> >>> The timestamp place holder in a log filename currently expands to
>> >>> the startup time of the JVM. When the log is rotated, the filename
>> >>> containing this timestamp is suffixed with a file number. My
>> >>> colleagues had expected the placeholder to be evaluated when the
>> >>> current log file is rotated. They expected the name of each rotated
>> >>> file to indicate the time the file was created. I think this
>> >>> expectation is not unreasonable, so I wanted to discuss the
>> >>> possibility of changing how/when the timestamp placeholder is
>> >>> evaluated. If there is any appetite for a change like this, I am
>> >>> willing to do the work. I would prefer to sort out the details
>> >>> before coding anything, rather than discussing them in a surprise
>> >>> pull request.
>> >>>
>> >>> Thank you for reading,
>> >>>
>> >>> William
>> >>>
>> >>
>> >
>>
> 


From kevin.walls at oracle.com  Fri Jan 31 08:08:22 2025
From: kevin.walls at oracle.com (Kevin Walls)
Date: Fri, 31 Jan 2025 08:08:22 +0000
Subject: Proposal to change the behavior of the timestamp place holder
 (%t) in log file paths
In-Reply-To: <9fc8ac63-5b69-4a99-9495-1ec6156bfe2c@oracle.com>
References: <0b5128abb575460490177c217ee6a4cc@amazon.com>
 <SN7PR10MB7032E048FC149ADDAE53BD5497EE2@SN7PR10MB7032.namprd10.prod.outlook.com>
 <b858cd3d-7086-4148-ad24-4d2393c522a3@oracle.com>
 <3f70b323-785a-4018-92e5-f9f65df7cc38@oracle.com>
 <2d17f01b-f23a-4292-8d45-2c739f6dfa77@oracle.com>
 <1343e908588646dba4795a3a0de6be2c@amazon.com>
 <67878131-7ddf-4354-a057-fdafd419afee@oracle.com>
 <9fc8ac63-5b69-4a99-9495-1ec6156bfe2c@oracle.com>
Message-ID: <SN7PR10MB70321243EBB68F84CEEC936E97E82@SN7PR10MB7032.namprd10.prod.outlook.com>


Also relevant are the jcmd commands that take an output filename.  Those have been updated to take %p pid (JDK-8334492) and there was some thought given to adding time/datestamp.  That didn't get completed but will hopefully still happen.

The title of JDK-8204681 might be out of date, it's not just hprof filenames, but all jcmd output files.  More info in https://github.com/openjdk/jdk/pull/20568

Good to keep these things consistent where we can.  8-)

Thanks
Kevin



-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.org> On Behalf Of David Holmes
Sent: Friday, January 31, 2025 2:58 AM
To: Larry Cable <larry.cable at oracle.com>; Kemper, William <kemperw at amazon.com>; serviceability-dev <serviceability-dev at openjdk.org>; hotspot-runtime-dev at openjdk.org
Subject: Re: Proposal to change the behavior of the timestamp place holder (%t) in log file paths

On 31/01/2025 4:03 am, Laurence Cable wrote:
> On 1/30/25 9:42 AM, Kemper, William wrote:
>>
>> Thank you all for your comments. We've gotten by using the pid (%p) 
>> as a means of grouping log files from a process. The log messages 
>> themselves include the uptime, so having the start time of the JVM in 
>> the file name has not been useful (and it would be trivial to add in 
>> from?startup scripts). I take your points about using the 
>> modification time of the files and will consider this.
>>
> 
> is not also the case that "trivial to add in from startup scripts" 
> also true for creation time?
> 
> perhaps propose a new substitution variable instead of redefining the 
> existing one?
> 
> e.g: %c

There has been some recent discussion (which I can't locate) about enabling various filename substitutions that match with the different Unified Logging timestamp decorators. Also Zhengyu just filed JDK-8349083.

David

> - Larry
> 
>> ---------------------------------------------------------------------
>> ---
>> *From:* Laurence Cable <larry.cable at oracle.com>
>> *Sent:* Thursday, January 30, 2025 9:14:53 AM
>> *To:* Kemper, William; serviceability-dev; David Holmes; hotspot- 
>> runtime-dev at openjdk.org
>> *Subject:* RE: [EXTERNAL] Proposal to change the behavior of the 
>> timestamp place holder (%t) in log file paths
>> CAUTION: This email originated from outside of the organization. Do 
>> not click links or open attachments unless you can confirm the sender 
>> and know the content is safe.
>>
>>
>>
>> On 1/29/25 5:56 PM, David Holmes wrote:
>> > Adding back serviceability-dev
>> >
>> > David
>> >
>> > On 30/01/2025 11:55 am, David Holmes wrote:
>> >> Plus one to what Kevin says. The current specified behaviour seems 
>> >> to me to be what would be generally desired. If there is a desire 
>> >> for a different kind of timestamp to be used then a proposal to 
>> >> add that would be more appropriate I think. I seem to recall 
>> >> something fairly recent about expanding the notion of "timestamp" that can be used here.
>>
>> +2 for Kevin and David's observations; changing the timestamp from 
>> +JVM
>> start time to create time, removes valuable and otherwise 
>> unobtainable (correlation) metadata from the logfile names, file 
>> creation and modification time is available from the underlying O.S 
>> filesystem if needed.
>>
>> Rgds
>>
>> - Larry
>>
>> >>
>> >> David
>> >>
>> >> On 29/01/2025 7:24 pm, Kevin Walls wrote:
>> >>> Hi,
>> >>>
>> >>> Just checking, but are they sure that's what they want? 8-)
>> >>>
>> >>> This relates to files from unified logging, like java - 
>> >>> Xlog:gc*:file%t.out ...creates: file2025-01-28_21-43-53.out and - 
>> >>> Xlog:help says, "If the filename contains %p, %t and/or %hn, they 
>> >>> will expand to the JVM's PID, startup timestamp and host name, 
>> >>> respectively."
>> >>>
>> >>> (Administratively, I think unified logging is under the runtime 
>> >>> group, cc?d.)
>> >>>
>> >>> Using the JVM start time, across all log files, identifies the 
>> >>> set of files that come from the same process.? They will 
>> >>> generally sort together when viewing a directory.? If a single 
>> >>> file gets copied around, it can still be traced back in its 
>> >>> group.?? When there are multiple sets of logs in the same 
>> >>> directory, the sets should still sort together.?? I see the 
>> >>> filename purpose as to identify the log, or set of logs.
>> >>>
>> >>> Using a new timestamp for each file, the filenames do not 
>> >>> identify the files as being part of the same run.? They may sort 
>> >>> together, but may not if another log series is in the same 
>> >>> directory, and once separated it's hard to regroup them.
>> >>>
>> >>> Using the pid as well will help, but if we see a lot of 
>> >>> low-numbered PIDs then this won't be unique. (With the current 
>> >>> startup timestamp, you will probably use %p for pid in the file 
>> >>> as well, in case JVMs start at the same moment.)
>> >>>
>> >>> Thanks
>> >>>
>> >>> Kevin
>> >>>
>> >>> *From:*serviceability-dev <serviceability-dev-retn at openjdk.org> 
>> >>> *On Behalf Of *Kemper, William
>> >>> *Sent:* Tuesday, January 28, 2025 7:54 PM
>> >>> *To:* serviceability-dev at openjdk.org
>> >>> *Subject:* Proposal to change the behavior of the timestamp place 
>> >>> holder (%t) in log file paths
>> >>>
>> >>> The timestamp place holder in a log filename currently expands to 
>> >>> the startup time of the JVM. When the log is rotated, the 
>> >>> filename containing this timestamp is suffixed with a file 
>> >>> number. My colleagues had expected the placeholder to be 
>> >>> evaluated when the current log file is rotated. They expected the 
>> >>> name of each rotated file to indicate the time the file was 
>> >>> created. I think this expectation is not unreasonable, so I 
>> >>> wanted to discuss the possibility of changing how/when the 
>> >>> timestamp placeholder is evaluated. If there is any appetite for 
>> >>> a change like this, I am willing to do the work. I would prefer 
>> >>> to sort out the details before coding anything, rather than 
>> >>> discussing them in a surprise pull request.
>> >>>
>> >>> Thank you for reading,
>> >>>
>> >>> William
>> >>>
>> >>
>> >
>>
> 


From mbaesken at openjdk.org  Fri Jan 31 08:14:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 31 Jan 2025 08:14:49 GMT
Subject: RFR: 8349039: Adjust exception No type named <ThreadType> in
 database
In-Reply-To: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
References: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
Message-ID: <k8C6ueCgsT9NkI0j2FR9gPmQGEhcur43QfBP5IW26YY=.6e6356b8-5ffa-4886-b34b-3bee4236ae62@github.com>

On Thu, 30 Jan 2025 10:22:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should the exception message from
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> to
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" present in type database
> 
> (like we have in some other exceptions in the same class)
> 
> error was (from [JDK-8348800](https://bugs.openjdk.org/browse/JDK-8348800)) :
> serviceability/sa/CDSJMapClstats.java
> 
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:320)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:116)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:128)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:95)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:86)
> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:137)
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:75)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23365#issuecomment-2626566809

From mbaesken at openjdk.org  Fri Jan 31 08:14:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 31 Jan 2025 08:14:50 GMT
Subject: Integrated: 8349039: Adjust exception No type named <ThreadType> in
 database
In-Reply-To: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
References: <pA7-reB3FlY726ROPwVU2iEHCVK3uf2b7ds8uLXwPng=.af9c0d71-695b-4001-aa3e-da41f756a793@github.com>
Message-ID: <QaC_oPLrtZ3LSb4MnHNKaFOWF-j7rMZnAMH0-m_4Sqk=.88c9c11b-1e94-46ec-801c-d56c8a306726@github.com>

On Thu, 30 Jan 2025 10:22:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should the exception message from
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> to
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" present in type database
> 
> (like we have in some other exceptions in the same class)
> 
> error was (from [JDK-8348800](https://bugs.openjdk.org/browse/JDK-8348800)) :
> serviceability/sa/CDSJMapClstats.java
> 
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.collectLiveRegions(ObjectHeap.java:320)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateSubtypes(ObjectHeap.java:216)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:116)
> at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.iterateObjectsOfKlass(ObjectHeap.java:128)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:95)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
> at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
> at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> Caused by: java.lang.RuntimeException: No type named "DeoptimizeObjectsALotThread" in database
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:86)
> at jdk.hotspot.agent/sun.jvm.hotspot.HotSpotTypeDataBase.lookupType(HotSpotTypeDataBase.java:137)
> at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.lookupType(BasicTypeDataBase.java:80)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:75)
> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)

This pull request has now been integrated.

Changeset: 669f8c0c
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/669f8c0c07b57fa00ac84b8a90c4a1a1459443e3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8349039: Adjust exception No type named <ThreadType> in database

Reviewed-by: kevinw, cjplummer

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

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

From amenkov at openjdk.org  Fri Jan 31 23:39:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 31 Jan 2025 23:39:28 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
Message-ID: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>

The fix implements streaming output support for attach protocol.
See JBS issue for evaluation, summary of the changes in the 1st comment.
Testing: tier1..4,hs-tier5-svc

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

Commit messages:
 - jcheck
 - jcheck
 - fix

Changes: https://git.openjdk.org/jdk/pull/23405/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23405&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319055
  Stats: 672 lines in 12 files changed: 493 ins; 60 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/23405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405

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

From amenkov at openjdk.org  Fri Jan 31 23:39:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 31 Jan 2025 23:39:28 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <zqyfANZZz1Wz0lUT4C_zNcXyWcQwiWoB5I31lqCnH3Y=.ad02db35-3136-48c1-aa78-a19dcddf8fcd@github.com>

On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

The changes:
Attach API protocol:
- attach operation options are added for ATTACH_API_V2 requests.
  The options are passed as part of command name; old clients old clients enquere command without options, new client adds options only if target VM support them, so there is no need to bump attach api version;
- "getversion" command supports new "options" argument. with this argument VM reports supported options.
The only supported option for now is "streaming" which allows client to control streaming/buffered output mode.

AttachListener:
- implemented attachStream class to support both streaming and buffered output;
- all attach command handler are updated to use attachStream instead of bufferedStream and start streaming (if enabled) after parsing command arguments;
- default streaming mode is controlled by "jdk.attach.vm.streaming" system properties; this value is used when clients does not specify "streaming" option in the request (for example when tools from older releases attach to the current VM). For safety now default value is "false" (i.e. buffered output). The plan is to make the default "true" later;
- platform implementations (windows/posix) updated accordingly shared code changes;

DCmd framework:
- added a way to start streaming output after command/argument parsing, but before executing the command;

Client side:
- added option support;
- added system property "jdk.attach.allowStreamingOutput" to set streaming mode;
  For now default value is "false" (i.e. to turn on streaming mode user need something like "JAVA_TOOL_OPTIONS=-Djdk.attach.allowStreamingOutput=true jcmd")
  The plan is to make the default "true" after fixing tests which fail with streaming output (or maybe add command line option for jcmd and other tools).

Test CodeHeapAnalyticsParams.java
- 'Compiler.CodeHeap_Analytics' jcmd command is the only command which thrown AttachOperationFailedException exception if argument is out of range (and this causes jcmd exits with exit code 1).
  All other jcmd commands just writes exception message in the output.
  Now 'Compiler.CodeHeap_Analytics' works like other commands, so the test is updated to expect exception message.

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2628559151