From schernyshev at openjdk.org  Sun Dec  1 12:51:44 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Sun, 1 Dec 2024 12:51:44 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <B69vtlp7QSapFHBgaBYgG-4bh3EL1Z7-IoqWIXI-v9E=.ca9b6db8-7c36-4caf-af32-8debf4f66313@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>
 <lYDiNahXCzv9TBqWvSQvUKemmO8F6tTcBaRz1VuSmeY=.310c5917-5f44-4142-8b16-b38ada5c3d25@github.com>
 <Fj67LWzsiCSVNUpf8BTvCTlOn2XpUWn6-Yf_9E-v9Ws=.51ec1fee-d023-4880-9b03-568cac720419@github.com>
 <BIQnvWnppBB3iUsIEJM5GnrQ7nnJsS2vOFv3SfwmSMc=.d040fba4-c280-4109-b6a9-1e170d9851ef@github.com>
 <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com>
 <kTtGWPheM8Y75kwHODKVK1fIi9zdbVW-iAJ2y1ePsfs=.bb7e233e-90eb-4315-9e2e-4406bf35b9d3@github.com>
 <O_JCPeqk--qL9NxQR0fCVqv7pL8l7_-mRoJXEqwoJhg=.5aaad8b6-3a6d-46a3-8fad-e79f400e8fea@github.com>
 <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com>
 <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx
 pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com>
 <eyBSQVEDfPzi7ryH1lDWVClDuBDjAwAfIGxkuGQM5e4=.8638be2d-7e95-425c-ae23-2ab8db725910@github.com>
 <ZvHcVnLWWgLDaMUDev3s9i617AxBxkKiTN9Iu2bzy1Y=.b6633b6d-f0a8-4320-9312-c04a7ffb6e87@github.com>
 <Ek8HlycNpj0wBTd7rIZXH6oRvKjtL8fAbYoC0qd57IE=.0c2ebd4d-8599-4578-ae48-4c2932d6a174@github.com>
 <U7e5bpUfD_u18ndqVbDMWwms-O8qoQqoigjS5Ri-ndY=.7b11767c-fda5-40c8-b062-2a55f8d66817@github.com>
 <B69vtlp7QSapFHBgaBYgG-4bh3EL1Z7-IoqWIXI-v9E=.ca9b6db8-7c36-4caf-af32-8debf4f66313@github.com>
Message-ID: <gifqRgLFhHJuJDQO0u3vsgCcw81-V96GEognDB53234=.14cf02d4-7172-456b-b690-ec204196d886@github.com>

On Fri, 29 Nov 2024 17:19:34 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> In the cloudflare case we'd end up with a subsystem path of `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`. Since the cgroup_path != _root we trigger path adjustment increasing the chance to detect any lower limit in any of the paths down to the mount point. By doing so **and** there is a lower limit in the hierarchy we know the path exists as well and that is being used from then on.

In the Cloudflare case (cg v1 before patch), the path `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c` will be adjusted as follows:

/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/
/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/
/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/
/sys/fs/cgroup/cpu,cpuacct/system.slice/
/sys/fs/cgroup/cpu,cpuacct/

In cg v1 systems, all the above paths except for the very last, are invalid. So, no chance for detecting any lower limits. When a process moved to a subgroup, the trailing part of cgroup_path will constitute the subgroup path.

> So if `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden` existed and has a limit it would be used. I thought this is the reason why cg v2 didn't need the same fix when `--cgroupns=host` is used.

The correct reasoning is the following: cg v2 didn't need the same fix, because in cg v2 the entire hierarchy is mapped inside the container in --cgroupns=host mode, the entire path is accessible, including the subgroup. In cg v1 only the process's cgroup is mapped, and the mapping includes subgroups, if any.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1864882109

From dholmes at openjdk.org  Mon Dec  2 00:14:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 00:14:48 GMT
Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and
 Thread.vthread_pollers diagnostic commands [v3]
In-Reply-To: <dgfsBaEGYL-iO-CzwDdnejH_dV6-lj-1T2t0Vpuq_Nw=.4b4ff10e-810e-4f6d-abbc-10d9e8d9665b@github.com>
References: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
 <dgfsBaEGYL-iO-CzwDdnejH_dV6-lj-1T2t0Vpuq_Nw=.4b4ff10e-810e-4f6d-abbc-10d9e8d9665b@github.com>
Message-ID: <T_kvqLJgHddrBLG5YFlk88puoW1f4c8iKHg92XkoI48=.afc835ca-64e4-46f0-af60-21fcd375fd33@github.com>

On Fri, 29 Nov 2024 11:12:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds `jcmd <pid> Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd <pid> Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations.
>> 
>> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort.
>> 
>> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337199
>  - VThread*Dcmd::execute changes to use helper function
>  - Improve regex for matching poller String representation
>  - Improve vthread_pollers output
>  - Merge branch 'master' into JDK-8337199
>  - Initial commit

LGTM! Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2471545814

From sgehwolf at openjdk.org  Mon Dec  2 10:49:38 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 10:49:38 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <gifqRgLFhHJuJDQO0u3vsgCcw81-V96GEognDB53234=.14cf02d4-7172-456b-b690-ec204196d886@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>
 <lYDiNahXCzv9TBqWvSQvUKemmO8F6tTcBaRz1VuSmeY=.310c5917-5f44-4142-8b16-b38ada5c3d25@github.com>
 <Fj67LWzsiCSVNUpf8BTvCTlOn2XpUWn6-Yf_9E-v9Ws=.51ec1fee-d023-4880-9b03-568cac720419@github.com>
 <BIQnvWnppBB3iUsIEJM5GnrQ7nnJsS2vOFv3SfwmSMc=.d040fba4-c280-4109-b6a9-1e170d9851ef@github.com>
 <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com>
 <kTtGWPheM8Y75kwHODKVK1fIi9zdbVW-iAJ2y1ePsfs=.bb7e233e-90eb-4315-9e2e-4406bf35b9d3@github.com>
 <O_JCPeqk--qL9NxQR0fCVqv7pL8l7_-mRoJXEqwoJhg=.5aaad8b6-3a6d-46a3-8fad-e79f400e8fea@github.com>
 <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com>
 <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx
 pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com>
 <eyBSQVEDfPzi7ryH1lDWVClDuBDjAwAfIGxkuGQM5e4=.8638be2d-7e95-425c-ae23-2ab8db725910@github.com>
 <ZvHcVnLWWgLDaMUDev3s9i617AxBxkKiTN9Iu2bzy1Y=.b6633b6d-f0a8-4320-9312-c04a7ffb6e87@github.com>
 <Ek8HlycNpj0wBTd7rIZXH6oRvKjtL8fAbYoC0qd57IE=.0c2ebd4d-8599-4578-ae48-4c2932d6a174@github.com>
 <U7e5bpUfD_u18ndqVbDMWwms-O8qoQqoigjS5Ri-ndY=.7b11767c-fda5-40c8-b062-2a55f8d66817@github.com>
 <B69vtlp7QSapFHBgaBYgG-4bh3EL1Z7-IoqWIXI-v9E=.ca9b6db8-7c36-4caf-af32-8debf4f66313@github.com>
 <gifqRgLFhHJuJDQO0u3vsgCcw81-V96GEognDB53234=.14cf02d4-7172-456b-b690-ec204196d886@github.com>
Message-ID: <s-asOdxK5dbZ5jBHzd6gJ7gEQ3Ek1Aajs877xb3sVBE=.80778f56-bdc1-41c6-9270-46aea91c03ff@github.com>

On Sun, 1 Dec 2024 12:48:40 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> In the Cloudflare case (cg v1 before patch), the path `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c` will be adjusted as follows:

I assume that's the adjustment logic (pre-patch) that happens provided the setting to `nullptr` issue is addressed in cg v1?

> ```
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/
> /sys/fs/cgroup/cpu,cpuacct/system.slice/
> /sys/fs/cgroup/cpu,cpuacct/
> ```
> 
> In cg v1 systems, all the above paths except for the very last, are invalid. So, no chance for detecting any lower limits. When a process moved to a subgroup, the trailing part of cgroup_path will constitute the subgroup path.

And after the patch this would become this, right?


/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
/sys/fs/cgroup/cpu,cpuacct/


If so, the change of logic isn't that different (except for where the existence checks are happening). This path adjustment only happens at boot, so the next look-up would use `/sys/fs/cgroup/cpu,cpuacct/`. So it's a trade-off, special case this use-case for added complexity or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1865630320

From schernyshev at openjdk.org  Mon Dec  2 11:13:43 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 2 Dec 2024 11:13:43 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <s-asOdxK5dbZ5jBHzd6gJ7gEQ3Ek1Aajs877xb3sVBE=.80778f56-bdc1-41c6-9270-46aea91c03ff@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>
 <lYDiNahXCzv9TBqWvSQvUKemmO8F6tTcBaRz1VuSmeY=.310c5917-5f44-4142-8b16-b38ada5c3d25@github.com>
 <Fj67LWzsiCSVNUpf8BTvCTlOn2XpUWn6-Yf_9E-v9Ws=.51ec1fee-d023-4880-9b03-568cac720419@github.com>
 <BIQnvWnppBB3iUsIEJM5GnrQ7nnJsS2vOFv3SfwmSMc=.d040fba4-c280-4109-b6a9-1e170d9851ef@github.com>
 <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com>
 <kTtGWPheM8Y75kwHODKVK1fIi9zdbVW-iAJ2y1ePsfs=.bb7e233e-90eb-4315-9e2e-4406bf35b9d3@github.com>
 <O_JCPeqk--qL9NxQR0fCVqv7pL8l7_-mRoJXEqwoJhg=.5aaad8b6-3a6d-46a3-8fad-e79f400e8fea@github.com>
 <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com>
 <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx
 pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com>
 <eyBSQVEDfPzi7ryH1lDWVClDuBDjAwAfIGxkuGQM5e4=.8638be2d-7e95-425c-ae23-2ab8db725910@github.com>
 <ZvHcVnLWWgLDaMUDev3s9i617AxBxkKiTN9Iu2bzy1Y=.b6633b6d-f0a8-4320-9312-c04a7ffb6e87@github.com>
 <Ek8HlycNpj0wBTd7rIZXH6oRvKjtL8fAbYoC0qd57IE=.0c2ebd4d-8599-4578-ae48-4c2932d6a174@github.com>
 <U7e5bpUfD_u18ndqVbDMWwms-O8qoQqoigjS5Ri-ndY=.7b11767c-fda5-40c8-b062-2a55f8d66817@github.com>
 <B69vtlp7QSapFHBgaBYgG-4bh3EL1Z7-IoqWIXI-v9E=.ca9b6db8-7c36-4caf-af32-8debf4f66313@github.com>
 <gifqRgLFhHJuJDQO0u3vsgCcw81-V96GEognDB53234=.14cf02d4-7172-456b-b690-ec204196d886@github.com>
 <s-asOdxK5dbZ5jBHzd6gJ7gEQ3Ek1Aajs877xb3sVBE=.80778f56-bdc1-41c6-9270-46aea91c03ff@github.com>
Message-ID: <OTqEYBfwvYOVD3v33bp1UR9ZaDWzhmnTxZyUAJLx0g8=.f3a682fa-e364-4a2d-b7d5-69e8620cb108@github.com>

On Mon, 2 Dec 2024 10:47:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> And after the patch this would become this, right?
> 
> ```
> /sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> /sys/fs/cgroup/cpu,cpuacct/
> ```

It depends on whether it was a subgroup in the initial path. If `bad/2f57368b-0eda-4e52-64d8-af5c` is the subgroup, the reduction will be

/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
/sys/fs/cgroup/cpu,cpuacct/bad/2f57368b-0eda-4e52-64d8-af5c
/sys/fs/cgroup/cpu,cpuacct/bad
/sys/fs/cgroup/cpu,cpuacct/

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1865663436

From jpai at openjdk.org  Mon Dec  2 12:20:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 12:20:08 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
Message-ID: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>

Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?

This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.

No new tests have been introduced and tier testing is currently in progress.

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

Commit messages:
 - update VectorIntrinsics too
 - 8345286: Remove use of SecurityManager API from misc areas

Changes: https://git.openjdk.org/jdk/pull/22478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345286
  Stats: 432 lines in 26 files changed: 53 ins; 320 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/22478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22478/head:pull/22478

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

From jpai at openjdk.org  Mon Dec  2 12:20:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 12:20:08 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <8vH0HsCLKLc0q4Th-IHRaUc96so5mpRz5V_3u_nYo-g=.01ab5dd0-59cb-46df-a4df-33610d2b1328@github.com>

On Mon, 2 Dec 2024 12:13:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Hello Severin  @jerboaa, given your work in the cgroups area of the JDK, could you help review the updates in this PR for those classes?

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

PR Comment: https://git.openjdk.org/jdk/pull/22478#issuecomment-2511382273

From alanb at openjdk.org  Mon Dec  2 12:49:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 12:49:39 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <aBSb3E0XBOW5dJRRyi6TjiW7K0lBDzgtw7DlnQGmj7k=.5d76ab9a-c6a3-4a0b-a605-73a1f47aad7e@github.com>

On Mon, 2 Dec 2024 12:13:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Good cleanup, a few small nits spotted along the way.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:

> 66: 
> 67:         try (BufferedReader bufferedReader =
> 68:                          Files.newBufferedReader(Paths.get(controller.path(), param))) {

The formatting has got messed up here. If you create `Path path = Path.of(controller.path(), param)` then the try line would fit on one line and would fix the formatting issue. Maybe some future cleanup will replace this with `Files.lines` as this just needs to return the first line.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 167:

> 165:         if (controller == null) return defaultRetval;
> 166: 
> 167:         try (Stream<String> lines = Files.lines(Paths.get(controller.path(), param))) {

Using Path.of might be clearer here.

src/java.base/share/classes/sun/reflect/misc/MethodUtil.java line 36:

> 34: import java.security.CodeSource;
> 35: import java.security.PermissionCollection;
> 36: import java.security.PrivilegedExceptionAction;

I'm half tempted to suggest leaving MethodUtil out of this change. There is further work required her and leaving the SM usage is a reminder of that.

src/java.management/share/classes/sun/management/VMManagementImpl.java line 249:

> 247: 
> 248:         // construct PerfInstrumentation object
> 249:         Perf perf =  Perf.getPerf();

An extra space crept in that at some point

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2472587775
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865783213
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865783907
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865778712
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865785944

From jpai at openjdk.org  Mon Dec  2 13:39:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 13:39:57 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:

 - remove unnecessary space
 - Path.of() instead of Paths.get()
 - fix formatting of try-with-resources in CgroupSubsystemController.java
 - leave out MethodUtil from the clean up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/e36c5207..75511e30

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

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

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

From jpai at openjdk.org  Mon Dec  2 13:39:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 13:39:59 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <aBSb3E0XBOW5dJRRyi6TjiW7K0lBDzgtw7DlnQGmj7k=.5d76ab9a-c6a3-4a0b-a605-73a1f47aad7e@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <aBSb3E0XBOW5dJRRyi6TjiW7K0lBDzgtw7DlnQGmj7k=.5d76ab9a-c6a3-4a0b-a605-73a1f47aad7e@github.com>
Message-ID: <QxEOKMo-tRIJt-_WfDnciSTiwSOUFCoE0LBG7b-hbYI=.44a3dcbd-c55e-411c-aaef-ca1a302bc3a5@github.com>

On Mon, 2 Dec 2024 12:42:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - leave out MethodUtil from the clean up
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:
> 
>> 66: 
>> 67:         try (BufferedReader bufferedReader =
>> 68:                          Files.newBufferedReader(Paths.get(controller.path(), param))) {
> 
> The formatting has got messed up here. If you create `Path path = Path.of(controller.path(), param)` then the try line would fit on one line and would fix the formatting issue. Maybe some future cleanup will replace this with `Files.lines` as this just needs to return the first line.

Fixed. I moved the `Path.of()` outside of the try-with-resources and the line length is now more reasonable.

> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 167:
> 
>> 165:         if (controller == null) return defaultRetval;
>> 166: 
>> 167:         try (Stream<String> lines = Files.lines(Paths.get(controller.path(), param))) {
> 
> Using Path.of might be clearer here.

Done, here and one other place in this file.

> src/java.base/share/classes/sun/reflect/misc/MethodUtil.java line 36:
> 
>> 34: import java.security.CodeSource;
>> 35: import java.security.PermissionCollection;
>> 36: import java.security.SecureClassLoader;
> 
> I'm half tempted to suggest leaving MethodUtil out of this change. There is further work required her and leaving the SM usage is a reminder of that.

Understood. I've now updated this PR to revert back the changes in this file.

> src/java.management/share/classes/sun/management/VMManagementImpl.java line 249:
> 
>> 247: 
>> 248:         // construct PerfInstrumentation object
>> 249:         Perf perf =  Perf.getPerf();
> 
> An extra space crept in that at some point

Thanks for spotting that, I hadn't noticed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865864725
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865865592
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865863888
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865865984

From sgehwolf at openjdk.org  Mon Dec  2 13:46:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 13:46:42 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
Message-ID: <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>

On Mon, 2 Dec 2024 13:39:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - remove unnecessary space
>  - Path.of() instead of Paths.get()
>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>  - leave out MethodUtil from the clean up

I've reviewed only the cgroups parts.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 70:

> 68:             String line = bufferedReader.readLine();
> 69:             return line;
> 70:         } catch (IOException e) {

We can use `Files.lines` here right away:

Suggestion:

        try (Stream<String> lines = Files.lines(filePath)) {
            Optional<String> firstLine = lines.findFirst();
            return firstLine.orElse(null);
        } catch (UncheckedIOException | IOException e) {

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 71:

> 69:             String line = bufferedReader.readLine();
> 70:             return line;
> 71:         } catch (IOException e) {

I think we can do this refactoring now:

Suggestion:

        try (Stream<String> lines =
                         Files.lines(Paths.of(controller.path(), param))) {
            Optional<String> firstLine = lines.findFirst();
            return firstLine.orElse(null);
        } catch (IOException e) {

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 332:

> 330: 
> 331:     private long sumTokensIOStat(Function<String, Long> mapFunc) {
> 332:         try (Stream<String> lines = Files.lines(Paths.get(unified.path(), "io.stat"))) {

Suggestion:

        try (Stream<String> lines = Files.lines(Paths.of(unified.path(), "io.stat"))) {

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 334:

> 332:         try (Stream<String> lines = Files.lines(Paths.get(unified.path(), "io.stat"))) {
> 333:             return lines.map(mapFunc)
> 334:                     .collect(Collectors.summingLong(e -> e));

Suggestion:

            return lines.map(mapFunc)
                        .collect(Collectors.summingLong(e -> e));

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

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2472643767
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865876078
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865860841
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865815063
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865865085

From sgehwolf at openjdk.org  Mon Dec  2 13:46:43 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 13:46:43 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <aBSb3E0XBOW5dJRRyi6TjiW7K0lBDzgtw7DlnQGmj7k=.5d76ab9a-c6a3-4a0b-a605-73a1f47aad7e@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <aBSb3E0XBOW5dJRRyi6TjiW7K0lBDzgtw7DlnQGmj7k=.5d76ab9a-c6a3-4a0b-a605-73a1f47aad7e@github.com>
Message-ID: <Hq8wXwalugmd_5_m2gjhTQrBMO9ZT8JwFz1-l41abFM=.091b7bdd-fd1f-4195-8508-d3515f592071@github.com>

On Mon, 2 Dec 2024 12:43:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - leave out MethodUtil from the clean up
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 167:
> 
>> 165:         if (controller == null) return defaultRetval;
>> 166: 
>> 167:         try (Stream<String> lines = Files.lines(Paths.get(controller.path(), param))) {
> 
> Using Path.of might be clearer here.

What Alan said.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865861779

From jpai at openjdk.org  Mon Dec  2 14:05:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:05:56 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v3]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <CJ6il3itTNXiRM24rTdG8c4Jmj_Bz0Xk4vokMRqT8-M=.0c164532-732a-4395-b712-616580d1f454@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Path.of() instead of Paths.get() in CgroupV2Subsystem.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/75511e30..ad62bd4c

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

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

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

From jpai at openjdk.org  Mon Dec  2 14:05:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:05:58 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
 <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
Message-ID: <WZ6jREp1LRBNufspyQqZls1ZtG99ItVKH1MgTOPXAzg=.f62f8549-dc14-481d-a5e5-dfa25a71b8fa@github.com>

On Mon, 2 Dec 2024 13:43:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - leave out MethodUtil from the clean up
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 70:
> 
>> 68:             String line = bufferedReader.readLine();
>> 69:             return line;
>> 70:         } catch (IOException e) {
> 
> We can use `Files.lines` here right away:
> 
> Suggestion:
> 
>         try (Stream<String> lines = Files.lines(filePath)) {
>             Optional<String> firstLine = lines.findFirst();
>             return firstLine.orElse(null);
>         } catch (UncheckedIOException | IOException e) {

Is the catch for `UncheckedIOException` due to some previously known failure resulting in the use of these APIs?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865907116

From jpai at openjdk.org  Mon Dec  2 14:05:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:05:59 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v3]
In-Reply-To: <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
 <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
Message-ID: <mFLPExBRx863Pu-nRDwBj-aSwD-O5WVunphsZVMUn9M=.85bba703-a1f7-442e-b0e8-074cdc6103ce@github.com>

On Mon, 2 Dec 2024 13:06:05 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 332:
> 
>> 330: 
>> 331:     private long sumTokensIOStat(Function<String, Long> mapFunc) {
>> 332:         try (Stream<String> lines = Files.lines(Paths.get(unified.path(), "io.stat"))) {
> 
> Suggestion:
> 
>         try (Stream<String> lines = Files.lines(Paths.of(unified.path(), "io.stat"))) {

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865903682

From jpai at openjdk.org  Mon Dec  2 14:10:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:10:58 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v4]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <pLcToi1ZCn82Tah-7tbsjKyjlinEVHeZCQrPxJa11Mk=.49aba38f-b3e0-46c6-b62c-715fd2b3fef5@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/ad62bd4c..52a47f72

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

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

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

From sgehwolf at openjdk.org  Mon Dec  2 14:10:58 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 14:10:58 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <WZ6jREp1LRBNufspyQqZls1ZtG99ItVKH1MgTOPXAzg=.f62f8549-dc14-481d-a5e5-dfa25a71b8fa@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
 <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
 <WZ6jREp1LRBNufspyQqZls1ZtG99ItVKH1MgTOPXAzg=.f62f8549-dc14-481d-a5e5-dfa25a71b8fa@github.com>
Message-ID: <FrSOROqsYjQOXAjB02I4UPCKz3y1ug8hzrX8irJMKoI=.4be1ce8f-6150-4289-bc59-18345868ac37@github.com>

On Mon, 2 Dec 2024 14:03:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 70:
>> 
>>> 68:             String line = bufferedReader.readLine();
>>> 69:             return line;
>>> 70:         } catch (IOException e) {
>> 
>> We can use `Files.lines` here right away:
>> 
>> Suggestion:
>> 
>>         try (Stream<String> lines = Files.lines(filePath)) {
>>             Optional<String> firstLine = lines.findFirst();
>>             return firstLine.orElse(null);
>>         } catch (UncheckedIOException | IOException e) {
>
> Is the catch for `UncheckedIOException` due to some previously known failure resulting in the use of these APIs?

Without using `Files.lines()` no `UncheckedIOException` would be thrown. Just `IOException` and `null` returned. This extra catch is there to avoid new `UncheckedIOException` being thrown on `findFirst()`. I.e. to keep semantics the same as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865913984

From jpai at openjdk.org  Mon Dec  2 14:16:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:16:02 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v5]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <btWExwZ8c0gZ-a5Fp6Xq8tGm88w_8_GkGa19EbUgXqk=.d2a56a20-b89b-45a3-a107-74c25af4c71d@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/52a47f72..26df25b2

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

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

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

From jpai at openjdk.org  Mon Dec  2 14:16:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:16:03 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v2]
In-Reply-To: <FrSOROqsYjQOXAjB02I4UPCKz3y1ug8hzrX8irJMKoI=.4be1ce8f-6150-4289-bc59-18345868ac37@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <i2ejYBG11uqFBDsnGWhds9FHrA_LjFAqoyHvCTMe9ZU=.a0c322f0-8b88-43af-a33a-f22493207f25@github.com>
 <guybik_gw85fqkI6fR5sm_2VaM13rMt7J-OmlENWUQk=.4acb43b3-2f4e-4780-a638-abe63b221a03@github.com>
 <WZ6jREp1LRBNufspyQqZls1ZtG99ItVKH1MgTOPXAzg=.f62f8549-dc14-481d-a5e5-dfa25a71b8fa@github.com>
 <FrSOROqsYjQOXAjB02I4UPCKz3y1ug8hzrX8irJMKoI=.4be1ce8f-6150-4289-bc59-18345868ac37@github.com>
Message-ID: <JW81IRQakdQs746uPvGf8UZhlUp7HIDEn2VW30QotkM=.51143cd4-fe2e-4fa6-9c51-27df539164ac@github.com>

On Mon, 2 Dec 2024 14:07:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Is the catch for `UncheckedIOException` due to some previously known failure resulting in the use of these APIs?
>
> Without using `Files.lines()` no `UncheckedIOException` would be thrown. Just `IOException` and `null` returned. This extra catch is there to avoid new `UncheckedIOException` being thrown on `findFirst()`. I.e. to keep semantics the same as before.

Thank you that's a good point. I hadn't taken into account exceptions propagated from `java.util.stream.Stream` operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865922009

From sgehwolf at openjdk.org  Mon Dec  2 14:19:40 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 14:19:40 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v5]
In-Reply-To: <btWExwZ8c0gZ-a5Fp6Xq8tGm88w_8_GkGa19EbUgXqk=.d2a56a20-b89b-45a3-a107-74c25af4c71d@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <btWExwZ8c0gZ-a5Fp6Xq8tGm88w_8_GkGa19EbUgXqk=.d2a56a20-b89b-45a3-a107-74c25af4c71d@github.com>
Message-ID: <0H2n9gkB0aX1Q_Iq9F45b7dKWq-plK3kBtb9eEQCZFc=.04ac9da1-7bcc-4938-9d96-d0cb422879fb@github.com>

On Mon, 2 Dec 2024 14:16:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>   
>   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

cgroups changes look good. Haven't looked at the other bits.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 29:

> 27: package jdk.internal.platform;
> 28: 
> 29: import java.io.BufferedReader;

Unused now?

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2472822295
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865928383

From jpai at openjdk.org  Mon Dec  2 14:24:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:24:57 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v6]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - remove unused import
 - replace remaining Paths.get() with Path.of() in the updated files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/26df25b2..b018ef09

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

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

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

From jpai at openjdk.org  Mon Dec  2 14:24:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:24:57 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v5]
In-Reply-To: <0H2n9gkB0aX1Q_Iq9F45b7dKWq-plK3kBtb9eEQCZFc=.04ac9da1-7bcc-4938-9d96-d0cb422879fb@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <btWExwZ8c0gZ-a5Fp6Xq8tGm88w_8_GkGa19EbUgXqk=.d2a56a20-b89b-45a3-a107-74c25af4c71d@github.com>
 <0H2n9gkB0aX1Q_Iq9F45b7dKWq-plK3kBtb9eEQCZFc=.04ac9da1-7bcc-4938-9d96-d0cb422879fb@github.com>
Message-ID: <WG7UyQILNyVy2rnFXmjSc-DDYzc6MYEeeZnaUidG56o=.be83594b-4994-42c2-8d61-df93927d1feb@github.com>

On Mon, 2 Dec 2024 14:17:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> cgroups changes look good. Haven't looked at the other bits.

Thank you Severin.

> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 29:
> 
>> 27: package jdk.internal.platform;
>> 28: 
>> 29: import java.io.BufferedReader;
> 
> Unused now?

Yes, it's now unused. I've removed it in the latest update to the PR and also replaced a few more Paths.get() with Path.of() in the current set of files that have been updated in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22478#issuecomment-2511675143
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865937624

From alanb at openjdk.org  Mon Dec  2 14:31:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 14:31:40 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v6]
In-Reply-To: <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
Message-ID: <zZrhdtFIU4Lk22YxW3E7eOjDj2H16Xc5S3eJJvfSxN8=.36d75d13-f80a-44f8-b886-a8e989fb6003@github.com>

On Mon, 2 Dec 2024 14:24:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files

Marked as reviewed by alanb (Reviewer).

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 3:

> 1: /*
> 2:  * Copyright (c) 2020, 2022, Red Hat Inc.
> 3:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Not sure about this as it's not a significant change to the file.

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

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2472853631
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865945081

From jpai at openjdk.org  Mon Dec  2 14:31:40 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 14:31:40 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v6]
In-Reply-To: <zZrhdtFIU4Lk22YxW3E7eOjDj2H16Xc5S3eJJvfSxN8=.36d75d13-f80a-44f8-b886-a8e989fb6003@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
 <zZrhdtFIU4Lk22YxW3E7eOjDj2H16Xc5S3eJJvfSxN8=.36d75d13-f80a-44f8-b886-a8e989fb6003@github.com>
Message-ID: <StYFcwU7FzTVhCr4QUu6Inws-7FpQxbRliFKdiRgwOo=.8ea683bd-6bee-4fa3-a456-562111bb7f5b@github.com>

On Mon, 2 Dec 2024 14:25:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove unused import
>>  - replace remaining Paths.get() with Path.of() in the updated files
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2020, 2022, Red Hat Inc.
>> 3:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Not sure about this as it's not a significant change to the file.

Do you mean for just this file or the rest of the files in this PR as well? I am open to removing the copyright additions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1865951827

From stuefe at openjdk.org  Mon Dec  2 14:55:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 2 Dec 2024 14:55:42 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
Message-ID: <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>

On Thu, 14 Nov 2024 14:13:16 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> Hi @stooke,
>> 
>> nice. There are some aspects about the output that is surprising, though. I expect reserved-only memory to be mapped with MAP_NORESERVE and no access rights. I expect committed memory to be mapped without MAP_NORESERVE and write- or executable access.
>> 
>> - (G1) I only see one segment for JAVAHEAP. I would expect at least two, one reserved-only, one reserved and committed. Or did you precommit the heap (start JVM with -Xmx==-Xms)? Can you please test that with ParallelGC and without specifying Xms, we should see four java heap mappings side by side, for young and old gen, each with a committed part (rw) and a reserved part (not accessible). Like we do now for the CODE section. Please also countercheck that the address ranges are correct against the heap range (easiest, run jcmd .. VM.info and look for the Heap section, it tells you the address ranges).
>> - The 64K META and CLASS blocks confuse me. For one, they are too small. A Metaspace node is 64M sized. It can contain multiple committed and reserved sections, so typically spreads over multiple lines, but usually not many. Here (G1 file), I see many that are 64K in size, spanning in total just about 5MB. You can counter-check the META blocks with `jcmd .. VM.metaspace vslist` - it prints the virtual space node list at the start.
>> - Another thing that is strange is that the MEAT lines are not coalesced, though the properties displayed seem to be the same. But that can be the result of hidden properties being different.
>> 
>> Also, could you rename the OS-specific names to `[lowercase-something]`? The `[UPPERCASE]` names are easily confused with the uppercase NMT tags.
>> 
>> Thanks!
>
> Hello, @tstuefe , and thanks for your comments.  I'll address a few here while I work on the others.
> I have changed the os-specific names to lowercase, but I don't think it makes them stand out more.  The square brackets were intended to do that.  Might I change this back?
> 
> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
> 
> I will look at the META and CLASS entries and see if there are hidden properties that I can surface, or if there's another reason for so many entries.
> 
> [1] I had given a target architecture to the configure command, which turned on cross-compiles (which disables CDS archive building) even when building on the target platform.

Hi @stooke !

> Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back?

Sure, if it looks worse. I just wanted to make sure we can cleanly distinguish NMT sections from OS sections.

> 
> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.

Has nothing to do with CDS. The heap consists of committed and reserved areas. Committed areas have backing swap space allocated for them, and are accessible. Reserved areas have not and are generally not. API wise the difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and are generally allocated with PROT_NONE. 

So, the heap should show up with several neighboring sections, some committed, some just reserved. Similar how most of the stacks should show up with two entries, one for the writable stack, one for the guard page that is protected.

---


Simple test I did on MacOS with your patch: I reserve 1G of memory at startup, uncommitted (added to os::init_2)


  if (UseNewCode) {
    char* p = os::reserve_memory(G, false, mtInternal);
    tty->print_cr("Pointer is %p", p);
  }



vmmap shows:


VM_ALLOCATE                 10ccb4000-14ccb4000    [  1.0G     0K     0K     0K] ---/rwx SM=NUL  


so, looks good. 1GB, with all protection flags cleared. But System.map shows nothing for this address range.


Now, I commit the second half of the range:



  if (UseNewCode) {
    char* p = os::reserve_memory(G, false, mtInternal);
    tty->print_cr("Pointer is %p", p);
    bool b = os::commit_memory(p + (512 * M), 512 * M, false);
    assert(b,"???");
  }


vmmap shows only the committed part now, omitting the still uncommitted first half. But it gets the protection flags right again (rw now):


VM_ALLOCATE (reserved)      148000000-168000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)


System.map shows nothing.


What goes on? Is the OS lying to us? Do we have an error? Both vmmap and System.map seem to struggle, with vmmap being somewhat more correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2511753610

From alanb at openjdk.org  Mon Dec  2 15:45:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 15:45:46 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v6]
In-Reply-To: <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
Message-ID: <r9sATWp-20Lzwb6BxJ5RAkXqQwshjvPCdsIb7_R_rWE=.fa7253a5-7087-4551-bfeb-3fe726d30d1a@github.com>

On Mon, 2 Dec 2024 14:24:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files

src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 129:

> 127:      * Create a RandomIO object for all I/O of this Variant type.
> 128:      */
> 129:     @SuppressWarnings("removal")

Sean has included in this one in the changes for sun.security (pull/22418) so I think you can drop it from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1866083497

From jpai at openjdk.org  Mon Dec  2 16:00:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 16:00:02 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v7]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <ARL3nnF2ha9xmyWaC7sDYrzwto5sN32OmFGRqka88ao=.9f7ce1e7-472a-4876-b9aa-d4b0fd842804@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22478/files
  - new: https://git.openjdk.org/jdk/pull/22478/files/b018ef09..5a96fa5f

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

  Stats: 101 lines in 1 file changed: 41 ins; 26 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/22478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22478/head:pull/22478

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

From jpai at openjdk.org  Mon Dec  2 16:00:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 16:00:02 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v7]
In-Reply-To: <r9sATWp-20Lzwb6BxJ5RAkXqQwshjvPCdsIb7_R_rWE=.fa7253a5-7087-4551-bfeb-3fe726d30d1a@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <XjBwmE1Y07eBHCW_jmqm0LV7EE-y6Lh4inpZcBevpVE=.66db5cae-2f5f-4904-bc10-7c8f17782a6f@github.com>
 <r9sATWp-20Lzwb6BxJ5RAkXqQwshjvPCdsIb7_R_rWE=.fa7253a5-7087-4551-bfeb-3fe726d30d1a@github.com>
Message-ID: <p6H3zk8w5QZldciL-5sEIRp1Q-Ab1SvdDH-LdM_Nu7A=.cf5c4a42-8d86-4012-ab92-28ea48c0309f@github.com>

On Mon, 2 Dec 2024 15:42:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>
> src/java.base/unix/classes/sun/security/provider/NativePRNG.java line 129:
> 
>> 127:      * Create a RandomIO object for all I/O of this Variant type.
>> 128:      */
>> 129:     private static RandomIO initIO(final Variant v) {
> 
> Sean has included in this one in the changes for sun.security (pull/22418) so I think you can drop it from this PR.

Done. Removed it from this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1866107838

From jpai at openjdk.org  Mon Dec  2 16:11:57 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 2 Dec 2024 16:11:57 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - merge latest from master branch
 - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
 - remove unused import
 - replace remaining Paths.get() with Path.of() in the updated files
 - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
 - remove unnecessary space
 - Path.of() instead of Paths.get()
 - fix formatting of try-with-resources in CgroupSubsystemController.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b

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

Changes: https://git.openjdk.org/jdk/pull/22478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22478&range=07
  Stats: 268 lines in 22 files changed: 8 ins; 226 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/22478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22478/head:pull/22478

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

From sgehwolf at openjdk.org  Mon Dec  2 16:55:46 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 2 Dec 2024 16:55:46 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
Message-ID: <0epWgcHJkEiBnsOtydW8sftZrLMxnODJDj7gw8z1AgY=.1208e089-9c22-4822-940c-f720d6080d1c@github.com>

On Mon, 2 Dec 2024 16:11:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - Path.of() instead of Paths.get()
>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b

cgroup changes still look good.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2473306738

From dfuchs at openjdk.org  Mon Dec  2 17:54:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 2 Dec 2024 17:54:44 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
Message-ID: <CGtAjlNEMJO5tyU8jksLf1oiG_7WbJbJtppjQAh412E=.a59f4f51-6748-4141-bca4-3a2355ab0c1c@github.com>

On Mon, 2 Dec 2024 16:11:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - Path.of() instead of Paths.get()
>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b

Good cleanup! Changes to logger + net look fine.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:

> 66:         try (Stream<String> lines = Files.lines(filePath)) {
> 67:             Optional<String> firstLine = lines.findFirst();
> 68:             return firstLine.orElse(null);

you could probably just:


            return lines.findFirst().orElse(null);


unless the local variable is needed or type inference?

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

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2473460631
PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1866322400

From mullan at openjdk.org  Mon Dec  2 18:50:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 2 Dec 2024 18:50:45 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
Message-ID: <rfyindH_TDtEU6qKs6k8X8YeOVxJ2Tp6cWEaEtAOkPw=.cc265c0f-680b-49c6-8f5f-3d49d0824d01@github.com>

On Mon, 2 Dec 2024 16:11:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - Path.of() instead of Paths.get()
>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b

src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 31:

> 29: 
> 30: /**
> 31:  * A thread that has no permissions, is not a member of any user-defined

I think you can also remove the words "has no permissions" as it no longer applies. @AlanBateman ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1866410247

From alanb at openjdk.org  Mon Dec  2 18:57:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 18:57:43 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <rfyindH_TDtEU6qKs6k8X8YeOVxJ2Tp6cWEaEtAOkPw=.cc265c0f-680b-49c6-8f5f-3d49d0824d01@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
 <rfyindH_TDtEU6qKs6k8X8YeOVxJ2Tp6cWEaEtAOkPw=.cc265c0f-680b-49c6-8f5f-3d49d0824d01@github.com>
Message-ID: <WXUbMUqdA-_nGEmjidRYXBlxEgBXdFsXR4uJKAg3T8Y=.9a9c3d68-140f-4808-89b9-66775ca7baac@github.com>

On Mon, 2 Dec 2024 18:48:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - merge latest from master branch
>>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>>  - remove unused import
>>  - replace remaining Paths.get() with Path.of() in the updated files
>>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b
>
> src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * A thread that has no permissions, is not a member of any user-defined
> 
> I think you can also remove the words "has no permissions" as it no longer applies. @AlanBateman ?

Yes, that can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1866425533

From kevinw at openjdk.org  Mon Dec  2 20:19:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 2 Dec 2024 20:19:12 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v9]
In-Reply-To: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
Message-ID: <trIOojWzrPkjuuYYpiH7GTQEh9A_VkDOghZuj8lNkv8=.49662ffb-522d-4fc4-b385-e41099b95a88@github.com>

> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).

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 17 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
 - Exception handling
 - tidyup
 - Suppression tidyup
 - unnecessary variables
 - remove redundant method
 - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
 - ReflectUtil removals
 - Remove checkPackageAccess calls
 - Remove Util.check... calls
 - ... and 7 more: https://git.openjdk.org/jdk/compare/7361fc8d...e525245b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22100/files
  - new: https://git.openjdk.org/jdk/pull/22100/files/9628234f..e525245b

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

  Stats: 57766 lines in 962 files changed: 39058 ins; 13125 del; 5583 mod
  Patch: https://git.openjdk.org/jdk/pull/22100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100

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

From jpai at openjdk.org  Tue Dec  3 06:12:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Dec 2024 06:12:13 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - merge latest from master branch
 - remove permission text from InnocuousThread
 - merge latest from master branch
 - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
 - remove unused import
 - replace remaining Paths.get() with Path.of() in the updated files
 - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
 - remove unnecessary space
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a3b58ee5...d53fe8ad

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

Changes: https://git.openjdk.org/jdk/pull/22478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22478&range=08
  Stats: 269 lines in 22 files changed: 8 ins; 226 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/22478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22478/head:pull/22478

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

From jpai at openjdk.org  Tue Dec  3 06:17:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Dec 2024 06:17:41 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <CGtAjlNEMJO5tyU8jksLf1oiG_7WbJbJtppjQAh412E=.a59f4f51-6748-4141-bca4-3a2355ab0c1c@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
 <CGtAjlNEMJO5tyU8jksLf1oiG_7WbJbJtppjQAh412E=.a59f4f51-6748-4141-bca4-3a2355ab0c1c@github.com>
Message-ID: <rruCpkAFUrXB80W0nb3K7y4Wm3Y_ctu1fLf9ZrsUqyc=.4e8e46e2-1e71-4f6e-abdd-ae3dd1959b77@github.com>

On Mon, 2 Dec 2024 17:47:57 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - merge latest from master branch
>>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>>  - remove unused import
>>  - replace remaining Paths.get() with Path.of() in the updated files
>>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>>  - remove unnecessary space
>>  - Path.of() instead of Paths.get()
>>  - fix formatting of try-with-resources in CgroupSubsystemController.java
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/30b8bbe2...9baa279b
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:
> 
>> 66:         try (Stream<String> lines = Files.lines(filePath)) {
>> 67:             Optional<String> firstLine = lines.findFirst();
>> 68:             return firstLine.orElse(null);
> 
> you could probably just:
> 
> 
>             return lines.findFirst().orElse(null);
> 
> 
> unless the local variable is needed or type inference?

Hello Daniel, no syntactical reason behind this. Severin proposed this style in his review and I noticed that this area of the code has been using this style of local variable assigment and immediate return in one or two other places, so I decided to stick with it. I don't have a strong preference but am willing to update it if you or others think we should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1867112305

From jpai at openjdk.org  Tue Dec  3 06:17:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Dec 2024 06:17:43 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <WXUbMUqdA-_nGEmjidRYXBlxEgBXdFsXR4uJKAg3T8Y=.9a9c3d68-140f-4808-89b9-66775ca7baac@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
 <rfyindH_TDtEU6qKs6k8X8YeOVxJ2Tp6cWEaEtAOkPw=.cc265c0f-680b-49c6-8f5f-3d49d0824d01@github.com>
 <WXUbMUqdA-_nGEmjidRYXBlxEgBXdFsXR4uJKAg3T8Y=.9a9c3d68-140f-4808-89b9-66775ca7baac@github.com>
Message-ID: <l7PNCQNujjJgopxFNHrGk2GeNcNPlEYpoI5WfhYVUds=.f7c89b7f-f87c-4c83-b154-29b599d3f3cb@github.com>

On Mon, 2 Dec 2024 18:54:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 31:
>> 
>>> 29: 
>>> 30: /**
>>> 31:  * A thread that has no permissions, is not a member of any user-defined
>> 
>> I think you can also remove the words "has no permissions" as it no longer applies. @AlanBateman ?
>
> Yes, that can be removed.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1867112404

From alanb at openjdk.org  Tue Dec  3 07:27:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 07:27:55 GMT
Subject: Integrated: 8337199: Add jcmd Thread.vthread_scheduler and
 Thread.vthread_pollers diagnostic commands
In-Reply-To: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
References: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
Message-ID: <gCyVjPoSxaXBug57O7wtoDKqTlo46XjgFNWCrtrzXU4=.66b11d1a-8beb-437a-b8ab-e4a5670eec8a@github.com>

On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Adds `jcmd <pid> Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd <pid> Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations.
> 
> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort.
> 
> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out.

This pull request has now been integrated.

Changeset: 5c8cb2ed
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c8cb2edcb0a919bfcad11b3f2cb399402915a0c
Stats:     391 lines in 11 files changed: 379 ins; 8 del; 4 mod

8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands

Reviewed-by: dholmes, kevinw

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

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

From alanb at openjdk.org  Tue Dec  3 08:14:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 08:14:42 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
Message-ID: <wrdd11yCpk1o4O4Bu8et28N90SGIGqzWmzQq6jz-k9E=.778ae060-4017-4afc-8e8b-2d2893749273@github.com>

On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge latest from master branch
>  - remove permission text from InnocuousThread
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a3b58ee5...d53fe8ad

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2474867316

From jpai at openjdk.org  Tue Dec  3 09:05:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Dec 2024 09:05:44 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
Message-ID: <YsvEdK2VFV5_4rcoUrHSyGOeGT2JqmsllwgMDjgfcho=.c7c272cc-a7eb-4427-bb18-df27e06ff9bb@github.com>

On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge latest from master branch
>  - remove permission text from InnocuousThread
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a3b58ee5...d53fe8ad

Although trivial, there are some changes to files from the serviceability area. So it would be good if someone from that area could review this too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22478#issuecomment-2513925153

From schernyshev at openjdk.org  Tue Dec  3 10:09:41 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 3 Dec 2024 10:09:41 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v8]
In-Reply-To: <qpI0PEaxhHvSLKRujwyDCsb8uUTQw2sQA2zomJW6cJc=.2dbb1062-31f4-401d-9a8c-46fe520895c4@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <qpI0PEaxhHvSLKRujwyDCsb8uUTQw2sQA2zomJW6cJc=.2dbb1062-31f4-401d-9a8c-46fe520895c4@github.com>
Message-ID: <pWWJSRLoCYOkMWwLoMBVpysmorlP0uQ5lAFqFu3umXA=.ee72e9a9-1f93-4557-b2dc-0f3d4a2ae044@github.com>

On Sat, 30 Nov 2024 00:30:02 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 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.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2514099036

From dfuchs at openjdk.org  Tue Dec  3 14:27:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 14:27:44 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v8]
In-Reply-To: <rruCpkAFUrXB80W0nb3K7y4Wm3Y_ctu1fLf9ZrsUqyc=.4e8e46e2-1e71-4f6e-abdd-ae3dd1959b77@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <GifqFgrSkaouhDjV7AN_IZjp0Hz9XJ6Ru5429P8_AGA=.c7cff6b9-a9dd-4f94-ae40-2efa3c2f02bd@github.com>
 <CGtAjlNEMJO5tyU8jksLf1oiG_7WbJbJtppjQAh412E=.a59f4f51-6748-4141-bca4-3a2355ab0c1c@github.com>
 <rruCpkAFUrXB80W0nb3K7y4Wm3Y_ctu1fLf9ZrsUqyc=.4e8e46e2-1e71-4f6e-abdd-ae3dd1959b77@github.com>
Message-ID: <0c8raXwIQzX4Bf5wUtextKqf7FfAXbX_wSizYcN2WAI=.9ccb62b7-65ce-423d-803f-981750611895@github.com>

On Tue, 3 Dec 2024 06:14:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java line 68:
>> 
>>> 66:         try (Stream<String> lines = Files.lines(filePath)) {
>>> 67:             Optional<String> firstLine = lines.findFirst();
>>> 68:             return firstLine.orElse(null);
>> 
>> you could probably just:
>> 
>> 
>>             return lines.findFirst().orElse(null);
>> 
>> 
>> unless the local variable is needed or type inference?
>
> Hello Daniel, no syntactical reason behind this. Severin proposed this style in his review and I noticed that this area of the code has been using this style of local variable assigment and immediate return in one or two other places, so I decided to stick with it. I don't have a strong preference but am willing to update it if you or others think we should.

In that case you may leave it as is - it's fine with me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22478#discussion_r1867819610

From cjplummer at openjdk.org  Tue Dec  3 18:05:17 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 18:05:17 GMT
Subject: RFR: 8345341: Fix incorrect log message in JDI stop002t test
Message-ID: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>

The log message is wrong. Copy-n-paste bug from another part of the test.

I'd like to push this as a trivial change.

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

Commit messages:
 - fix log message

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

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

From cjplummer at openjdk.org  Tue Dec  3 19:07:44 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 19:07:44 GMT
Subject: RFR: 8345148: Fix for JDK-8337317 is incomplete
In-Reply-To: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com>
References: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com>
Message-ID: <O8phmTA1T381H5eGQsfTbrVzpwzPOosv-KCTWfzsiV8=.d6d95a93-ee21-4214-8ec0-e21fadd57841@github.com>

On Thu, 28 Nov 2024 01:30:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fix for JDK-8337317 (#20699) updated serviceability/jvmti/HiddenClass and serviceability/jvmti/VMObjectAlloc tests adding guards against JVMTI_ERROR_WRONG_PHASE errors, but missed to enable JVMTI_EVENT_VM_DEATH events.
> This fix adds the missed part.
> 
> Testing: hotspot/jtreg/serviceability/jvmti on all platforms
> Manually verified test outputs contain "VMDeath" notification from VMDeath callback

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22426#pullrequestreview-2476565352

From cjplummer at openjdk.org  Tue Dec  3 19:08:40 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 19:08:40 GMT
Subject: RFR: 8344987: Test
 serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails:
 NoClassDefFoundError: jdk/test/lib/Utils
In-Reply-To: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
Message-ID: <LpZyZNcTTtYmLWV706jm6-v8wD6WvuRuCb7SFyf-Ip4=.ded33e36-d99d-43ab-b40f-dd4f39f43804@github.com>

On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The real bug is
> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library
> 
> and the following workaround just excludes the testing group where it fails often. 
> 
> There is no plans to update test right now. The jtreg should be fixed.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22405#pullrequestreview-2476567147

From pchilanomate at openjdk.org  Tue Dec  3 20:11:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 3 Dec 2024 20:11:53 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
Message-ID: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>

Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.

Thanks,
Patricio

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

Commit messages:
 - v1

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

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

From amenkov at openjdk.org  Tue Dec  3 20:17:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 3 Dec 2024 20:17:39 GMT
Subject: RFR: 8345341: Fix incorrect log message in JDI stop002t test
In-Reply-To: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
References: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
Message-ID: <cIplqwtDoxsl2Sp8IXz3oOIA5385nKckpgPFINMv0Og=.d417b64f-1b1c-4913-a0a7-079e3f9b3a3f@github.com>

On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The log message is wrong. Copy-n-paste bug from another part of the test.
> 
> I'd like to push this as a trivial change.

Looks good and trivial

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22499#pullrequestreview-2476660769

From cjplummer at openjdk.org  Tue Dec  3 20:22:52 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 20:22:52 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the debug
 agent and debugger tests
Message-ID: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>

The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.

Testing in progress:
- [ ] All tier1
- [ ] All tier2 svc tests
- [ ] All tier3 svc tests
- [ ] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
- [ ] All tier5 svc tests

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

Commit messages:
 - Fix some debugger related JNI Checker warnings.

Changes: https://git.openjdk.org/jdk/pull/22528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345422
  Stats: 108 lines in 9 files changed: 64 ins; 24 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/22528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22528/head:pull/22528

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

From lmesnik at openjdk.org  Tue Dec  3 20:35:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Dec 2024 20:35:48 GMT
Subject: Integrated: 8344987: Test
 serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails:
 NoClassDefFoundError: jdk/test/lib/Utils
In-Reply-To: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
Message-ID: <tLru6IHLhTdNIbO6UWFuj8gwwhnH0U7FRI6xoqmL6Kw=.36750b3b-697f-4b2d-89c8-03491cc1e5a8@github.com>

On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The real bug is
> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library
> 
> and the following workaround just excludes the testing group where it fails often. 
> 
> There is no plans to update test right now. The jtreg should be fixed.

This pull request has now been integrated.

Changeset: 0664b517
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0664b517650c622dcf21f8bd2e3e389e7d81bbab
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils

Reviewed-by: cjplummer

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

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

From cjplummer at openjdk.org  Tue Dec  3 22:29:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 22:29:38 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <Cr--c5PHWveYOF79XSj6_RxXdmpKr2todb7RwOZ2-UA=.cf75de01-75d6-4661-886a-df1d6dc2cfcb@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing in progress:
> - [ ] All tier1
> - [ ] All tier2 svc tests
> - [ ] All tier3 svc tests
> - [ ] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [ ] All tier5 svc tests

src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c line 685:

> 683: 
> 684:     /* Clear any exception thrown while handling the event. */
> 685:     JNI_FUNC_PTR(env,ExceptionClear)(env);

For those doing the review, the rethrowing of the exception has moved into threadControl_onEventHandlerExit(), which is called below. The rethrowing needs to occur after the last findRunningThread() call since that triggers a call to JNI IsVirtualThread(), which shouldn't be called with a pending exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1868445641

From lmesnik at openjdk.org  Tue Dec  3 22:52:39 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Dec 2024 22:52:39 GMT
Subject: RFR: 8345341: Fix incorrect log message in JDI stop002t test
In-Reply-To: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
References: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
Message-ID: <GgKs2pe-3jsz6bRMMUm1APGLKXCzh6g20gcO79Q-cDQ=.aea920ee-7b29-41b7-be5e-163ae2476592@github.com>

On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The log message is wrong. Copy-n-paste bug from another part of the test.
> 
> I'd like to push this as a trivial change.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22499#pullrequestreview-2476907619

From coleenp at openjdk.org  Tue Dec  3 23:00:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 23:00:37 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <xCBI5JCMILoD-f0Ec5WI5NEHktmOVa8Z9dQ2h7UrJqA=.32609b13-0626-458b-93c3-32eb96f27421@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Renaming looks good and makes it clearer what the id is.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2476917190

From cjplummer at openjdk.org  Wed Dec  4 00:18:41 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 00:18:41 GMT
Subject: RFR: 8345341: Fix incorrect log message in JDI stop002t test
In-Reply-To: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
References: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
Message-ID: <KFrL-ISgv-xz4uu0W1wIYYMpZDKJQHysOJjH_gb4rFc=.0e317568-7331-4775-864d-581c63617909@github.com>

On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The log message is wrong. Copy-n-paste bug from another part of the test.
> 
> I'd like to push this as a trivial change.

Thanks Alex and Leonid!

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

PR Comment: https://git.openjdk.org/jdk/pull/22499#issuecomment-2515851469

From cjplummer at openjdk.org  Wed Dec  4 00:18:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 00:18:42 GMT
Subject: Integrated: 8345341: Fix incorrect log message in JDI stop002t test
In-Reply-To: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
References: <Wdpk1R2tvVmJjChgnwyfnpfDSQACA33GIiMqrg6nQG8=.1ea535ed-d4f7-4d1f-aa5b-9c2148ff7548@github.com>
Message-ID: <5J_S3e0q8LgB1cT3OhYHpPDJOEERyhpjoT9nNL9AIDw=.33a5ec7b-3fff-4a9a-8490-b94275f9bb7c@github.com>

On Mon, 2 Dec 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The log message is wrong. Copy-n-paste bug from another part of the test.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 42378970
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42378970e1accc67c2a152c6af2b0becacf5b4b8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8345341: Fix incorrect log message in JDI stop002t test

Reviewed-by: amenkov, lmesnik

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

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

From dholmes at openjdk.org  Wed Dec  4 01:47:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 01:47:39 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Thanks for making the changes.

One minor nit, but looks good.

src/hotspot/share/runtime/javaThread.hpp line 174:

> 172:   void set_monitor_owner_id(int64_t val) {
> 173:     assert(val >= ThreadIdentifier::initial() && val < ThreadIdentifier::current(), "");
> 174:     _monitor_owner_id = val;

Nit: Using `id`  rather than `val` would be more consistent with other changes (`ObjectMonitor::owner_id_from`)

src/hotspot/share/runtime/threads.cpp line 1363:

> 1361:         p->print_stack_on(st);
> 1362:         if (p->is_vthread_mounted()) {
> 1363:           st->print_cr("   Mounted virtual thread #" INT64_FORMAT, java_lang_Thread::thread_id(p->vthread()));

Was initially unsure why `p->lock_id()` didn't change to `p->monitor_owner_id()`, but here you want the thread-id not something that happens to match the thread-id.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2477079004
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1868577497
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1868580851

From dholmes at openjdk.org  Wed Dec  4 02:15:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 02:15:42 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

Mostly seems okay but one issue with the exception clearing.

Thanks

src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c line 56:

> 54:         JNI_FUNC_PTR(env,ExceptionClear)(env); // keep -Xcheck:jni happy
> 55:         ERROR_MESSAGE(("JNI Exception occurred calling Module.getName()"));
> 56:         EXIT_ERROR(AGENT_ERROR_JNI_EXCEPTION, NULL);

Don't you want to report what the exception was?

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

PR Review: https://git.openjdk.org/jdk/pull/22528#pullrequestreview-2477106633
PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1868595575

From amenkov at openjdk.org  Wed Dec  4 03:12:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Dec 2024 03:12:08 GMT
Subject: RFR: 8305010: Test
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
 timed out: thread not suspended
Message-ID: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>

The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and agent thread:
The callbacks increments event counter and then do self-suspend;
Agent thread waits when expected number of events is received, then performs verification and resumes the thread, but expected counter value does not mean the threads are suspended.

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

Commit messages:
 - fix

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

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

From cjplummer at openjdk.org  Wed Dec  4 04:55:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 04:55:38 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>
Message-ID: <IXbnWS694vLNOgStyIveYu05sUbY3Hn3GDp9msvlNb0=.0dd745bf-4958-42c4-a924-a25a526d4110@github.com>

On Wed, 4 Dec 2024 02:07:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
>> 
>> Testing:
>> - [x] All tier1
>> - [x] All tier2 svc tests
>> - [x] All tier3 svc tests
>> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
>> - [x] All tier5 svc tests
>
> src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c line 56:
> 
>> 54:         JNI_FUNC_PTR(env,ExceptionClear)(env); // keep -Xcheck:jni happy
>> 55:         ERROR_MESSAGE(("JNI Exception occurred calling Module.getName()"));
>> 56:         EXIT_ERROR(AGENT_ERROR_JNI_EXCEPTION, NULL);
> 
> Don't you want to report what the exception was?

That might be nice, but we don't do it in other places where we have this pattern. This call should never fail, thus the "fatal error" approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1868716747

From cjplummer at openjdk.org  Wed Dec  4 05:02:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 05:02:37 GMT
Subject: RFR: 8305010: Test
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
 timed out: thread not suspended
In-Reply-To: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
References: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
Message-ID: <o7doo9Se-wXJbs5t_yJ-GifyeVCOo1y-aTjO7lQNHog=.247c9048-e531-47de-bb11-90d5ef3dd096@github.com>

On Wed, 4 Dec 2024 03:07:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and agent thread:
> The callbacks increments event counter and then do self-suspend;
> Agent thread waits when expected number of events is received, then performs verification and resumes the thread, but expected counter value does not mean the threads are suspended.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22532#pullrequestreview-2477292135

From dholmes at openjdk.org  Wed Dec  4 05:40:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 05:40:37 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <IXbnWS694vLNOgStyIveYu05sUbY3Hn3GDp9msvlNb0=.0dd745bf-4958-42c4-a924-a25a526d4110@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>
 <IXbnWS694vLNOgStyIveYu05sUbY3Hn3GDp9msvlNb0=.0dd745bf-4958-42c4-a924-a25a526d4110@github.com>
Message-ID: <IAxgJH4Ymw_X7OqbNBen7lq7CsKMFl2ww_pfgXAfWXo=.7a78379d-ad78-4543-ae7f-7569a3c6e00f@github.com>

On Wed, 4 Dec 2024 04:53:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c line 56:
>> 
>>> 54:         JNI_FUNC_PTR(env,ExceptionClear)(env); // keep -Xcheck:jni happy
>>> 55:         ERROR_MESSAGE(("JNI Exception occurred calling Module.getName()"));
>>> 56:         EXIT_ERROR(AGENT_ERROR_JNI_EXCEPTION, NULL);
>> 
>> Don't you want to report what the exception was?
>
> That might be nice, but we don't do it in other places where we have this pattern. This call should never fail, thus the "fatal error" approach.

Sure but when it does fail because of a bug the person trying to debug it will lament the fact they don't know what exception was encountered. Seems a little helper function could do the above and call `ExceptionDescribe`. Future RFE I guess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1868747644

From cjplummer at openjdk.org  Wed Dec  4 05:59:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 05:59:38 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <IAxgJH4Ymw_X7OqbNBen7lq7CsKMFl2ww_pfgXAfWXo=.7a78379d-ad78-4543-ae7f-7569a3c6e00f@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>
 <IXbnWS694vLNOgStyIveYu05sUbY3Hn3GDp9msvlNb0=.0dd745bf-4958-42c4-a924-a25a526d4110@github.com>
 <IAxgJH4Ymw_X7OqbNBen7lq7CsKMFl2ww_pfgXAfWXo=.7a78379d-ad78-4543-ae7f-7569a3c6e00f@github.com>
Message-ID: <UWoN-cxS7OIJqr0OSzqRAY2GflltH5PeCA2snXyvaJM=.927f135d-fca5-4d9c-bd7d-acb59e4adaff@github.com>

On Wed, 4 Dec 2024 05:38:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> That might be nice, but we don't do it in other places where we have this pattern. This call should never fail, thus the "fatal error" approach.
>
> Sure but when it does fail because of a bug the person trying to debug it will lament the fact they don't know what exception was encountered. Seems a little helper function could do the above and call `ExceptionDescribe`. Future RFE I guess.

I was thinking the same. I'll file an RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1868763345

From dholmes at openjdk.org  Wed Dec  4 06:12:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 06:12:38 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <x4Kmo73pybNpvRD78oG1pu32yw3gw1bFK8B8yNrl5Y8=.f0191347-7f94-43ea-85d4-28a890989d50@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22528#pullrequestreview-2477379212

From kevinw at openjdk.org  Wed Dec  4 09:27:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 09:27:47 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
Message-ID: <j9ZmyPzBL36w-HSnR3pDW_EHga1ona8Hz5KSYPYbfKo=.3d449ee9-1dcd-4450-8e09-601c2ac40832@github.com>

On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge latest from master branch
>  - remove permission text from InnocuousThread
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a3b58ee5...d53fe8ad

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22478#pullrequestreview-2477811501

From kevinw at openjdk.org  Wed Dec  4 09:27:47 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 09:27:47 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <YsvEdK2VFV5_4rcoUrHSyGOeGT2JqmsllwgMDjgfcho=.c7c272cc-a7eb-4427-bb18-df27e06ff9bb@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
 <YsvEdK2VFV5_4rcoUrHSyGOeGT2JqmsllwgMDjgfcho=.c7c272cc-a7eb-4427-bb18-df27e06ff9bb@github.com>
Message-ID: <5T_Z02TfiPQwilJrJCO5UWozEie4YvLiOFBzXrYXPQA=.6394958e-9a42-4dc2-b881-792dc05ee4d6@github.com>

On Tue, 3 Dec 2024 09:03:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Although trivial, there are some changes to files from the serviceability area. So it would be good if someone from that area could review this too.

Yes, looks good.  I will update https://github.com/openjdk/jdk/pull/22478 to avoid the clash!

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

PR Comment: https://git.openjdk.org/jdk/pull/22478#issuecomment-2516659181

From jpai at openjdk.org  Wed Dec  4 09:27:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Dec 2024 09:27:48 GMT
Subject: RFR: 8345286: Remove use of SecurityManager API from misc areas
 [v9]
In-Reply-To: <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
 <sPE7T9TB0AsoLKptOGsVbSio7rLTuQ-OPpkKp6Vc90Q=.26f1ee03-2645-40ae-afcc-920dc3b97c1c@github.com>
Message-ID: <vkPu0zGzTeNLL9O0M2j5paRZ4iIc3BPiFvh-rV6YiOQ=.b1c63b25-3bfe-4df4-b944-6a3f0145f431@github.com>

On Tue, 3 Dec 2024 06:12:13 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
>> 
>> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
>> 
>> No new tests have been introduced and tier testing is currently in progress.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - merge latest from master branch
>  - remove permission text from InnocuousThread
>  - merge latest from master branch
>  - remove changes to src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>  - remove unused import
>  - replace remaining Paths.get() with Path.of() in the updated files
>  - Update src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Update src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Path.of() instead of Paths.get() in CgroupV2Subsystem.java
>  - remove unnecessary space
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a3b58ee5...d53fe8ad

Thank you everyone for the help in reviewing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22478#issuecomment-2516665394

From jpai at openjdk.org  Wed Dec  4 09:27:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 4 Dec 2024 09:27:48 GMT
Subject: Integrated: 8345286: Remove use of SecurityManager API from misc areas
In-Reply-To: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
References: <KrF61mEv_gI5fftZ8Dmw0YGsXfpebrOblTW1YRRTK-g=.0f16e23c-bad7-4ece-b577-467d1ed2aa60@github.com>
Message-ID: <WozXRDcK9rViC4L89mZIC-Mc-LmX6_Rwe1Rs2Rvh8_M=.8d829481-ebc3-4346-b0db-69ce23d3a284@github.com>

On Mon, 2 Dec 2024 12:13:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which removes usages of SecurityManager related APIs and some leftover related to SecurityManager changes?
> 
> This addresses https://bugs.openjdk.org/browse/JDK-8345286. Most of these changes are trivial. The `src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java` used to expose utility methods for dealing with SecurityManager permissions and it was called from a few places. That class is no longer needed with the clean up done in this PR.
> 
> No new tests have been introduced and tier testing is currently in progress.

This pull request has now been integrated.

Changeset: 3d49665b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d49665b85619038c082566b0bc38c0ebe5f752e
Stats:     269 lines in 22 files changed: 8 ins; 226 del; 35 mod

8345286: Remove use of SecurityManager API from misc areas

Reviewed-by: alanb, kevinw, sgehwolf

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

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

From kevinw at openjdk.org  Wed Dec  4 10:16:53 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 10:16:53 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
Message-ID: <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>

> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge
 - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
 - Exception handling
 - tidyup
 - Suppression tidyup
 - unnecessary variables
 - remove redundant method
 - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
 - ReflectUtil removals
 - Remove checkPackageAccess calls
 - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f

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

Changes: https://git.openjdk.org/jdk/pull/22100/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=09
  Stats: 1573 lines in 64 files changed: 10 ins; 1360 del; 203 mod
  Patch: https://git.openjdk.org/jdk/pull/22100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100

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

From kevinw at openjdk.org  Wed Dec  4 10:20:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 10:20:43 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
Message-ID: <JpstA3aBMchXDtWaPTMkD_lIqbU-gvHGbTcMP-TuSkM=.63d6c844-c60c-4230-ad05-2fac82c9c042@github.com>

On Wed, 4 Dec 2024 10:16:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - Exception handling
>  - tidyup
>  - Suppression tidyup
>  - unnecessary variables
>  - remove redundant method
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - ReflectUtil removals
>  - Remove checkPackageAccess calls
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f

Merged with master after PR 22478 is integrated - that had the same changes for src/java.management/share/classes/sun/management/VMManagementImpl.java
(that file is still appears in this PR with a change, as I'd removed another of the existing extra spaces).

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

PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2516850015

From dfuchs at openjdk.org  Wed Dec  4 13:10:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Dec 2024 13:10:42 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
Message-ID: <OzBQAJgxiFY2PnpmPCvhiBWyVrVVxo652fRcWMmx9fk=.721bcbdc-457f-4e48-a4fe-24a469854366@github.com>

On Wed, 4 Dec 2024 10:16:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - Exception handling
>  - tidyup
>  - Suppression tidyup
>  - unnecessary variables
>  - remove redundant method
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - ReflectUtil removals
>  - Remove checkPackageAccess calls
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f

src/java.management/share/classes/javax/management/MBeanServerFactory.java line 368:

> 366: 
> 367:         // No context class loader? Try with Class.forName()
> 368:         return Class.forName(builderClassName);

Maybe we should keep that call to ReflectUtil here for the moment?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1869463223

From alanb at openjdk.org  Wed Dec  4 13:15:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 13:15:53 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <OzBQAJgxiFY2PnpmPCvhiBWyVrVVxo652fRcWMmx9fk=.721bcbdc-457f-4e48-a4fe-24a469854366@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
 <OzBQAJgxiFY2PnpmPCvhiBWyVrVVxo652fRcWMmx9fk=.721bcbdc-457f-4e48-a4fe-24a469854366@github.com>
Message-ID: <yT3rHh9DXfP4fTaxyXU3ZxTXq6XeRf8bZ_-hAPBS2wY=.ea81c273-4b3a-4df8-bcc9-e4e24bd45025@github.com>

On Wed, 4 Dec 2024 13:08:05 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 pull request now contains 18 commits:
>> 
>>  - Merge
>>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>>  - Exception handling
>>  - tidyup
>>  - Suppression tidyup
>>  - unnecessary variables
>>  - remove redundant method
>>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>>  - ReflectUtil removals
>>  - Remove checkPackageAccess calls
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f
>
> src/java.management/share/classes/javax/management/MBeanServerFactory.java line 368:
> 
>> 366: 
>> 367:         // No context class loader? Try with Class.forName()
>> 368:         return Class.forName(builderClassName);
> 
> Maybe we should keep that call to ReflectUtil here for the moment?

The java.management module is mapped to the boot loader so it's okay to replace the use of ReflectUtil.forName with Class.forName here (no behavior change).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1869470860

From dfuchs at openjdk.org  Wed Dec  4 13:21:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Dec 2024 13:21:48 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
Message-ID: <_TNnPJ2s1ROhtOBpGB0QUJMcvJnXTUfkXT3Je8TzDBI=.4f6dc6fb-07f5-4454-96bf-ce9de12b91d8@github.com>

On Wed, 4 Dec 2024 10:16:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - Exception handling
>  - tidyup
>  - Suppression tidyup
>  - unnecessary variables
>  - remove redundant method
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - ReflectUtil removals
>  - Remove checkPackageAccess calls
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f

Looks good to me

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22100#pullrequestreview-2478567220
PR Review: https://git.openjdk.org/jdk/pull/22100#pullrequestreview-2478571963

From kevinw at openjdk.org  Wed Dec  4 13:21:49 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 13:21:49 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
Message-ID: <QYXb391i0K6GC4syXsHAVsH2Tzpgt94MqKbPJhxW9L0=.e020441e-a880-4422-ba9c-a15512dae78b@github.com>

On Wed, 4 Dec 2024 10:16:53 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Remove redundant SecurityManager, AccessController references
>> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - Exception handling
>  - tidyup
>  - Suppression tidyup
>  - unnecessary variables
>  - remove redundant method
>  - Merge remote-tracking branch 'upstream/master' into java_management_post_sm
>  - ReflectUtil removals
>  - Remove checkPackageAccess calls
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/994504c3...1437532f

Thanks Daniel, and thanks for the discussion above.

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

PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2517327662

From dfuchs at openjdk.org  Wed Dec  4 13:21:50 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 4 Dec 2024 13:21:50 GMT
Subject: RFR: 8344177: Remove SecurityManager and related calls from
 java.management [v10]
In-Reply-To: <yT3rHh9DXfP4fTaxyXU3ZxTXq6XeRf8bZ_-hAPBS2wY=.ea81c273-4b3a-4df8-bcc9-e4e24bd45025@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
 <1yDCFH53l6iVfHF1nlYj2UxB0j7zjPuiUtEh0KHBclI=.e50f445b-77c8-4277-9eac-9d42b72795fd@github.com>
 <OzBQAJgxiFY2PnpmPCvhiBWyVrVVxo652fRcWMmx9fk=.721bcbdc-457f-4e48-a4fe-24a469854366@github.com>
 <yT3rHh9DXfP4fTaxyXU3ZxTXq6XeRf8bZ_-hAPBS2wY=.ea81c273-4b3a-4df8-bcc9-e4e24bd45025@github.com>
Message-ID: <Bf_T01IQnpxspcjx_7mEI3QAsml8D1PzB1u2_JSlWgI=.9ad93fc2-7e20-4b3e-be19-d28785e10579@github.com>

On Wed, 4 Dec 2024 13:13:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/MBeanServerFactory.java line 368:
>> 
>>> 366: 
>>> 367:         // No context class loader? Try with Class.forName()
>>> 368:         return Class.forName(builderClassName);
>> 
>> Maybe we should keep that call to ReflectUtil here for the moment?
>
> The java.management module is mapped to the boot loader so it's okay to replace the use of ReflectUtil.forName with Class.forName here (no behavior change).

OK - I withdraw my objection then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1869478007

From kevinw at openjdk.org  Wed Dec  4 14:25:51 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Dec 2024 14:25:51 GMT
Subject: Integrated: 8344177: Remove SecurityManager and related calls from
 java.management
In-Reply-To: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
References: <likOkOp6K5ug_1Vjaqp6Ax9fKph8RHF9jaBuJJ3gfuQ=.3269e780-4e7b-42a4-aa95-69694d1d6e33@github.com>
Message-ID: <J50GWg1At8xFhtsoZcdYMqk9SPgLYGBB1AbsWZojASk=.9a1cfe01-60fa-42fc-a912-f82a7a415751@github.com>

On Thu, 14 Nov 2024 10:39:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove redundant SecurityManager, AccessController references
> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager).

This pull request has now been integrated.

Changeset: bd6d911c
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd6d911cbe4b04221e52120cd0f8f04e219eca4d
Stats:     1573 lines in 64 files changed: 10 ins; 1360 del; 203 mod

8344177: Remove SecurityManager and related calls from java.management

Reviewed-by: dfuchs

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

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

From pchilanomate at openjdk.org  Wed Dec  4 15:47:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 15:47:26 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix parameter name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22524/files
  - new: https://git.openjdk.org/jdk/pull/22524/files/108abc2b..8cfc9a10

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

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

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

From pchilanomate at openjdk.org  Wed Dec  4 15:47:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 15:47:26 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>
Message-ID: <-c_LKYc0sEMbVtxPOCYWt8Fv2L-XoBfY9kmyDbNbhfg=.7b9bf7cf-1f46-471e-b184-5253add1f846@github.com>

On Wed, 4 Dec 2024 01:36:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix parameter name
>
> src/hotspot/share/runtime/javaThread.hpp line 174:
> 
>> 172:   void set_monitor_owner_id(int64_t val) {
>> 173:     assert(val >= ThreadIdentifier::initial() && val < ThreadIdentifier::current(), "");
>> 174:     _monitor_owner_id = val;
> 
> Nit: Using `id`  rather than `val` would be more consistent with other changes (`ObjectMonitor::owner_id_from`)

Fixed.

> src/hotspot/share/runtime/threads.cpp line 1363:
> 
>> 1361:         p->print_stack_on(st);
>> 1362:         if (p->is_vthread_mounted()) {
>> 1363:           st->print_cr("   Mounted virtual thread #" INT64_FORMAT, java_lang_Thread::thread_id(p->vthread()));
> 
> Was initially unsure why `p->lock_id()` didn't change to `p->monitor_owner_id()`, but here you want the thread-id not something that happens to match the thread-id.

Exactly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1869818716
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1869819018

From cjplummer at openjdk.org  Wed Dec  4 18:28:41 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 18:28:41 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <OGOf_--RgWH5glgFw_I7Rl0leaIZSFQNZLg_j_-dwxs=.f9bc0566-4c82-4b7d-a4bb-27840f313337@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

Thanks for the review, David!

Can I please get a 2nd review. I'd like to push before the branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/22528#issuecomment-2518215251

From cjplummer at openjdk.org  Wed Dec  4 18:28:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 18:28:42 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <UWoN-cxS7OIJqr0OSzqRAY2GflltH5PeCA2snXyvaJM=.927f135d-fca5-4d9c-bd7d-acb59e4adaff@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <_0nlvE4FGTtGnuzZoCoejHZJ_gFirKLptpqbfAz5B80=.ae41ab64-3a33-4b68-b03a-b94449cb6a1d@github.com>
 <IXbnWS694vLNOgStyIveYu05sUbY3Hn3GDp9msvlNb0=.0dd745bf-4958-42c4-a924-a25a526d4110@github.com>
 <IAxgJH4Ymw_X7OqbNBen7lq7CsKMFl2ww_pfgXAfWXo=.7a78379d-ad78-4543-ae7f-7569a3c6e00f@github.com>
 <UWoN-cxS7OIJqr0OSzqRAY2GflltH5PeCA2snXyvaJM=.927f135d-fca5-4d9c-bd7d-acb59e4adaff@github.com>
Message-ID: <2M9NuHaIa7B5cN9e69iM3BCm6QbGoDNeNxf9YIAoc5E=.75ea6720-d249-4c06-a312-0a41ebfd7136@github.com>

On Wed, 4 Dec 2024 05:56:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Sure but when it does fail because of a bug the person trying to debug it will lament the fact they don't know what exception was encountered. Seems a little helper function could do the above and call `ExceptionDescribe`. Future RFE I guess.
>
> I was thinking the same. I'll file an RFE.

Filed [JDK-8345515](https://bugs.openjdk.org/browse/JDK-8345515)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870071713

From coleenp at openjdk.org  Wed Dec  4 19:08:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Dec 2024 19:08:13 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
Message-ID: <NGQLIbLf5E5mAhtLmis1zVrAXOstJ74vpNu7eS1ygpE=.3f99064a-1914-4be8-8676-5bbba13b8fec@github.com>

On Wed, 4 Dec 2024 15:47:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix parameter name

Update looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2479668829

From stooke at openjdk.org  Wed Dec  4 19:59:55 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 4 Dec 2024 19:59:55 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v10]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <fb_Iuk9S8GzRREKpS3B4PSC3Sdjy5iRi7HJUmWY072A=.e395b7ea-7531-4be6-b4aa-772379ccd9da@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  latest cleanup, get rid of dll info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/38021267..7fddda4c

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

  Stats: 206 lines in 2 files changed: 26 ins; 161 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/20953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953

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

From stooke at openjdk.org  Wed Dec  4 20:03:42 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 4 Dec 2024 20:03:42 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
Message-ID: <oXDAF-clcb0852YXRPCwFbhkDE9ogiSTrQA2Y4H9OMw=.d979c07c-c5b1-415c-881a-91a7fb7b25b7@github.com>

On Mon, 2 Dec 2024 14:52:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello, @tstuefe , and thanks for your comments.  I'll address a few here while I work on the others.
>> I have changed the os-specific names to lowercase, but I don't think it makes them stand out more.  The square brackets were intended to do that.  Might I change this back?
>> 
>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
>> 
>> I will look at the META and CLASS entries and see if there are hidden properties that I can surface, or if there's another reason for so many entries.
>> 
>> [1] I had given a target architecture to the configure command, which turned on cross-compiles (which disables CDS archive building) even when building on the target platform.
>
> Hi @stooke !
> 
>> Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back?
> 
> Sure, if it looks worse. I just wanted to make sure we can cleanly distinguish NMT sections from OS sections.
> 
>> 
>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
> 
> Has nothing to do with CDS. The heap consists of committed and reserved areas. Committed areas have backing swap space allocated for them, and are accessible. Reserved areas have not and are generally not. API wise the difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and are generally allocated with PROT_NONE. 
> 
> So, the heap should show up with several neighboring sections, some committed, some just reserved. Similar how most of the stacks should show up with two entries, one for the writable stack, one for the guard page that is protected.
> 
> ---
> 
> 
> Simple test I did on MacOS with your patch: I reserve 1G of memory at startup, uncommitted (added to os::init_2)
> 
> 
>   if (UseNewCode) {
>     char* p = os::reserve_memory(G, false, mtInternal);
>     tty->print_cr("Pointer is %p", p);
>   }
> 
> 
> 
> vmmap shows:
> 
> 
> VM_ALLOCATE                 10ccb4000-14ccb4000    [  1.0G     0K     0K     0K] ---/rwx SM=NUL  
> 
> 
> so, looks good. 1GB, with all protection flags cleared. But System.map shows nothing for this address range.
> 
> 
> Now, I commit the second half of the range:
> 
> 
> 
>   if (UseNewCode) {
>     char* p = os::reserve_memory(G, false, mtInternal);
>     tty->print_cr("Pointer is %p", p);
>     bool b = os::commit_memory(p + (512 * M), 512 * M, false);
>     assert(b,"???");
>   }
> 
> 
> vmmap shows only the committed part now, omitting the still uncommitted first half. But it gets the protection flags right again (rw now):
> 
> 
> VM_ALLOCATE (reserved)      148000000-168000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)
> 
> 
> System.map shows nothing.
> 
> 
> What goes on? Is the OS lying to us? Do we have an error? Both vmmap and System.map seem to struggle, with vmmap being somewhat more correct.

@tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free".  
As to the strange vmmap behaviour, I found that the two sections appeared in different places:
the uncommitted spaces appeared in "==== Non-writable regions for process":
`VM_ALLOCATE                 300000000-320000000    [512.0M     0K     0K     0K] ---/rwx SM=NUL  
`
and the committed spaces in "==== Writable regions for process":
`VM_ALLOCATE (reserved)      320000000-340000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)
`
I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output.
[vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2518444621

From stooke at openjdk.org  Wed Dec  4 20:20:16 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 4 Dec 2024 20:20:16 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v11]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <cnqHOu3yELbruqjvj8-bZvN2azt_bjUAKqW6pndu77U=.8df72185-ec29-40d4-8a99-e7b5bab4de07@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  fix trailing whitesdpae errors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/7fddda4c..07184546

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

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

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

From amenkov at openjdk.org  Wed Dec  4 20:50:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Dec 2024 20:50:43 GMT
Subject: Integrated: 8345148: Fix for JDK-8337317 is incomplete
In-Reply-To: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com>
References: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com>
Message-ID: <W4wxuyHePNtdqmq5B2DTtLAPjr8Zz656o8xlczvRAq8=.a9e7c9c1-2338-4dce-bdae-e9cf71d6e3fa@github.com>

On Thu, 28 Nov 2024 01:30:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Fix for JDK-8337317 (#20699) updated serviceability/jvmti/HiddenClass and serviceability/jvmti/VMObjectAlloc tests adding guards against JVMTI_ERROR_WRONG_PHASE errors, but missed to enable JVMTI_EVENT_VM_DEATH events.
> This fix adds the missed part.
> 
> Testing: hotspot/jtreg/serviceability/jvmti on all platforms
> Manually verified test outputs contain "VMDeath" notification from VMDeath callback

This pull request has now been integrated.

Changeset: a72cab8c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a72cab8c47955e643330d5c3fbf599f2716277b9
Stats:     12 lines in 2 files changed: 10 ins; 0 del; 2 mod

8345148: Fix for JDK-8337317 is incomplete

Reviewed-by: lmesnik, cjplummer

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

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

From amenkov at openjdk.org  Wed Dec  4 21:15:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Dec 2024 21:15:38 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 342:

> 340: 
> 341: static void
> 342: saveGlobalRefHelper(JNIEnv *env, jobject obj, jobject *pobj)

Do we need to call `saveGlobalRefHelper` instead of `saveGlobalRef `in `invokeNonvirtual`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870286694

From cjplummer at openjdk.org  Wed Dec  4 21:20:40 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 21:20:40 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
Message-ID: <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>

On Wed, 4 Dec 2024 21:12:57 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
>> 
>> Testing:
>> - [x] All tier1
>> - [x] All tier2 svc tests
>> - [x] All tier3 svc tests
>> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
>> - [x] All tier5 svc tests
>
> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 342:
> 
>> 340: 
>> 341: static void
>> 342: saveGlobalRefHelper(JNIEnv *env, jobject obj, jobject *pobj)
> 
> Do we need to call `saveGlobalRefHelper` instead of `saveGlobalRef `in `invokeNonvirtual`?

I don't believe so because if an object is returned then that implies that there was no exception thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870291602

From pchilanomate at openjdk.org  Wed Dec  4 21:28:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 21:28:47 GMT
Subject: Integrated: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <E499NqnB06_eCIvFDcBXM3XEGVGYLOUapfd89hsIbyI=.6ee58bb9-b7a1-4f4f-b3b1-c0a1f723c488@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: c113f82f
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c113f82f78c7d9be1ac297aebfeb6051f0f904fb
Stats:     83 lines in 19 files changed: 0 ins; 2 del; 81 mod

8343957: Rename ObjectMonitor::owner_from() and JavaThread::_lock_id

Reviewed-by: coleenp, dholmes

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

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

From pchilanomate at openjdk.org  Wed Dec  4 21:28:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 21:28:46 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
Message-ID: <hVBseQjbCZe-_o7YhA0CdDgv6gWDaGGD8D3z9fWkfsE=.40e9f97a-b073-4e02-a4fb-4ad0d889f11a@github.com>

On Wed, 4 Dec 2024 15:47:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix parameter name

Thanks for the reviews Coleen and David!

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

PR Comment: https://git.openjdk.org/jdk/pull/22524#issuecomment-2518592483

From amenkov at openjdk.org  Wed Dec  4 21:51:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Dec 2024 21:51:43 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
 <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
Message-ID: <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>

On Wed, 4 Dec 2024 21:18:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 342:
>> 
>>> 340: 
>>> 341: static void
>>> 342: saveGlobalRefHelper(JNIEnv *env, jobject obj, jobject *pobj)
>> 
>> Do we need to call `saveGlobalRefHelper` instead of `saveGlobalRef `in `invokeNonvirtual`?
>
> I don't believe so because if an object is returned then that implies that there was no exception thrown.

It's the same like other calls here (invokeVirtual, etc), so I'd expect it produces "in native method" warning.
Maybe we don't have a test for this so this case is not detected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870326129

From cjplummer at openjdk.org  Wed Dec  4 22:17:39 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 22:17:39 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
 <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
 <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>
Message-ID: <mksnV7J5Qtvty-Pj9Z22mKyy8sZZbyx5Iee4JvR0jCk=.5d82573f-41ca-47b4-8dda-6f5bcf6135d6@github.com>

On Wed, 4 Dec 2024 21:49:05 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> I don't believe so because if an object is returned then that implies that there was no exception thrown.
>
> It's the same like other calls here (invokeVirtual, etc), so I'd expect it produces "in native method" warning.
> Maybe we don't have a test for this so this case is not detected?

I think there are two types of checks for exceptions; implicit and explicit.

For the implicit check, the "call" functions all set a flag saying an exception check is needed. So this will trigger the "in native method" warning on the next call regardless of whether or not an exception is actually thrown. What I'm not so sure of is which JNI functions check this flag (I know only the "call" functions set it). Since we don't see a warning for this saveGlobalRef() case, I'm inclined to think that NewGlobalRef does not check the flag.

I believe (but I'm not sure) there is also a second type of check that is explicit and only made to see if there is actually a pending exception when the JNI API is called. Possibly this check is done on all calls, but this saveGlobalRef() case never triggers it because there can't be a pending exception if an object was returned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870353181

From amenkov at openjdk.org  Wed Dec  4 22:59:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 4 Dec 2024 22:59:42 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <mksnV7J5Qtvty-Pj9Z22mKyy8sZZbyx5Iee4JvR0jCk=.5d82573f-41ca-47b4-8dda-6f5bcf6135d6@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
 <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
 <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>
 <mksnV7J5Qtvty-Pj9Z22mKyy8sZZbyx5Iee4JvR0jCk=.5d82573f-41ca-47b4-8dda-6f5bcf6135d6@github.com>
Message-ID: <uvXtHGZJwjtmVQ2gcZbACdVp-qH-ePO_QOICfGN1RDI=.c46082a1-f7b9-4264-9a1a-136894b7541f@github.com>

On Wed, 4 Dec 2024 22:15:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> What I'm not so sure of is which JNI functions check this flag (I know only the "call" functions set it)

In `invokeNonVirtual` we calls `CallNonvirtualObjectMethodA` JNI function and then call `saveGlobalRef`, it looks strange if the case don't cause the warning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870389138

From cjplummer at openjdk.org  Wed Dec  4 23:05:39 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 4 Dec 2024 23:05:39 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests
In-Reply-To: <uvXtHGZJwjtmVQ2gcZbACdVp-qH-ePO_QOICfGN1RDI=.c46082a1-f7b9-4264-9a1a-136894b7541f@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
 <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
 <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>
 <mksnV7J5Qtvty-Pj9Z22mKyy8sZZbyx5Iee4JvR0jCk=.5d82573f-41ca-47b4-8dda-6f5bcf6135d6@github.com>
 <uvXtHGZJwjtmVQ2gcZbACdVp-qH-ePO_QOICfGN1RDI=.c46082a1-f7b9-4264-9a1a-136894b7541f@github.com>
Message-ID: <eTDyK9ilRHb5Qd55BaOnwFiBZvHOUfqhQ6wOPTWUupI=.b9734662-7615-4fc4-a95d-d5aa59a06872@github.com>

On Wed, 4 Dec 2024 22:56:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> I think there are two types of checks for exceptions; implicit and explicit.
>> 
>> For the implicit check, the "call" functions all set a flag saying an exception check is needed. So this will trigger the "in native method" warning on the next call regardless of whether or not an exception is actually thrown. What I'm not so sure of is which JNI functions check this flag (I know only the "call" functions set it). Since we don't see a warning for this saveGlobalRef() case, I'm inclined to think that NewGlobalRef does not check the flag.
>> 
>> I believe (but I'm not sure) there is also a second type of check that is explicit and only made to see if there is actually a pending exception when the JNI API is called. Possibly this check is done on all calls, but this saveGlobalRef() case never triggers it because there can't be a pending exception if an object was returned.
>
>> What I'm not so sure of is which JNI functions check this flag (I know only the "call" functions set it)
> 
> In `invokeNonVirtual` we calls `CallNonvirtualObjectMethodA` JNI function and then call `saveGlobalRef`, it looks strange if the case don't cause the warning.

I've not sure if NewGlobalRef checks the flag or only checks if there is actually a pending exception. I'm trying to find that out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870393773

From cjplummer at openjdk.org  Thu Dec  5 00:56:25 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 00:56:25 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v2]
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <aqWOdstelA810KE37pQyUYgE3y-U2iGyOujSGv1MGG4=.0f2fe48b-ad37-4217-8a31-933537627f54@github.com>

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  use saveGlobalRefHelper() for invokeNonvirtual()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22528/files
  - new: https://git.openjdk.org/jdk/pull/22528/files/c4e5ffd1..3d524c85

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

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

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

From cjplummer at openjdk.org  Thu Dec  5 00:56:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 00:56:26 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v2]
In-Reply-To: <eTDyK9ilRHb5Qd55BaOnwFiBZvHOUfqhQ6wOPTWUupI=.b9734662-7615-4fc4-a95d-d5aa59a06872@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <Ib-VoESME3tJNXGQrtpYw3WvT5OA75FYqDJ4kfnXwB8=.36dff69c-518a-4b74-bacf-af8b11bddfa8@github.com>
 <M915qvcJm2boATxFRfjeads7k_mVbed7YAH_uVeo26g=.1daf4f05-21cc-4b80-a741-737e1568d255@github.com>
 <_bgM1QWN1-dd7p4w57-DGWR41Rh-ndV1PH4403jUtLs=.1c1b3538-fd1d-41ca-bef2-2a3ec74f2791@github.com>
 <mksnV7J5Qtvty-Pj9Z22mKyy8sZZbyx5Iee4JvR0jCk=.5d82573f-41ca-47b4-8dda-6f5bcf6135d6@github.com>
 <uvXtHGZJwjtmVQ2gcZbACdVp-qH-ePO_QOICfGN1RDI=.c46082a1-f7b9-4264-9a1a-136894b7541f@github.com>
 <eTDyK9ilRHb5Qd55BaOnwFiBZvHOUfqhQ6wOPTWUupI=.b9734662-7615-4fc4-a95d-d5aa59a06872@github.com>
Message-ID: <bCm_31IwwK9M2RoCR1GANjE0YdM3gvSCekfTVoj35Qs=.d4f7bd9e-be41-4d7e-8ae5-3061fb50ccd8@github.com>

On Wed, 4 Dec 2024 23:02:32 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> What I'm not so sure of is which JNI functions check this flag (I know only the "call" functions set it)
>> 
>> In `invokeNonVirtual` we calls `CallNonvirtualObjectMethodA` JNI function and then call `saveGlobalRef`, it looks strange if the case don't cause the warning.
>
> I've not sure if NewGlobalRef checks the flag or only checks if there is actually a pending exception. I'm trying to find that out.

Looks like we don't have a test case for invokeNonVirtual with an Object result. I'll update this to use saveGlobalRefHelper() also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870467853

From cjplummer at openjdk.org  Thu Dec  5 01:21:26 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 01:21:26 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v3]
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <5asxxgru45O3ToSPekt2GK9XwT-jqP4LYDaasmQO8HQ=.23e9a0a4-24af-4f07-aabe-e3954df33627@github.com>

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  get rid of temporary debugging assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22528/files
  - new: https://git.openjdk.org/jdk/pull/22528/files/3d524c85..f65afdf1

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

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

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

From cjplummer at openjdk.org  Thu Dec  5 01:21:27 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 01:21:27 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v2]
In-Reply-To: <aqWOdstelA810KE37pQyUYgE3y-U2iGyOujSGv1MGG4=.0f2fe48b-ad37-4217-8a31-933537627f54@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <aqWOdstelA810KE37pQyUYgE3y-U2iGyOujSGv1MGG4=.0f2fe48b-ad37-4217-8a31-933537627f54@github.com>
Message-ID: <MxPZiHpDeMY-oLWM-tYrFESTP4RnlVK3mjFCZ6E7KIU=.3c2faca1-c0ab-4994-bcb0-433a7a9cd539@github.com>

On Thu, 5 Dec 2024 00:56:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
>> 
>> Testing:
>> - [x] All tier1
>> - [x] All tier2 svc tests
>> - [x] All tier3 svc tests
>> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
>> - [x] All tier5 svc tests
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use saveGlobalRefHelper() for invokeNonvirtual()

src/jdk.jdwp.agent/share/native/libjdwp/invoker.c line 564:

> 562:         request->returnValue.l = NULL;
> 563:         if (object != NULL) {
> 564:             JDI_ASSERT_MSG(JNI_FALSE, "invokeNonvirtual with Object returned type");

Sorry, this crept in last commit. I'll remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22528#discussion_r1870483169

From amenkov at openjdk.org  Thu Dec  5 01:29:45 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 5 Dec 2024 01:29:45 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v3]
In-Reply-To: <5asxxgru45O3ToSPekt2GK9XwT-jqP4LYDaasmQO8HQ=.23e9a0a4-24af-4f07-aabe-e3954df33627@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <5asxxgru45O3ToSPekt2GK9XwT-jqP4LYDaasmQO8HQ=.23e9a0a4-24af-4f07-aabe-e3954df33627@github.com>
Message-ID: <MuTZyKbz99zFjxFWVXOsYWqy8kFIoyResAichtt4Idk=.bae3986b-fbfe-4304-b445-399166b4f798@github.com>

On Thu, 5 Dec 2024 01:21:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
>> 
>> Testing:
>> - [x] All tier1
>> - [x] All tier2 svc tests
>> - [x] All tier3 svc tests
>> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
>> - [x] All tier5 svc tests
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of temporary debugging assert

Thanks, looks good to me

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22528#pullrequestreview-2480235219

From cjplummer at openjdk.org  Thu Dec  5 03:36:49 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 03:36:49 GMT
Subject: RFR: 8345422: Fix JNI Checker "in native method" warnings in the
 debug agent and debugger tests [v3]
In-Reply-To: <5asxxgru45O3ToSPekt2GK9XwT-jqP4LYDaasmQO8HQ=.23e9a0a4-24af-4f07-aabe-e3954df33627@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
 <5asxxgru45O3ToSPekt2GK9XwT-jqP4LYDaasmQO8HQ=.23e9a0a4-24af-4f07-aabe-e3954df33627@github.com>
Message-ID: <ledGNkDttxKwClLCvITlOvO_2ROlUR1pbMSKa88p1aY=.a2a22fbd-eba4-4264-94dc-0ae1a399ea42@github.com>

On Thu, 5 Dec 2024 01:21:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
>> 
>> Testing:
>> - [x] All tier1
>> - [x] All tier2 svc tests
>> - [x] All tier3 svc tests
>> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
>> - [x] All tier5 svc tests
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get rid of temporary debugging assert

Thanks for the reviews Alex and David!

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

PR Comment: https://git.openjdk.org/jdk/pull/22528#issuecomment-2519013603

From cjplummer at openjdk.org  Thu Dec  5 03:36:50 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 5 Dec 2024 03:36:50 GMT
Subject: Integrated: 8345422: Fix JNI Checker "in native method" warnings in
 the debug agent and debugger tests
In-Reply-To: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
References: <2ScMe8XCu9sW_gl9syhcwUTOJNrTIVJkfxvaSK4zVrM=.447f37aa-aa2a-47b8-980f-87a6f5f2aae2@github.com>
Message-ID: <mdiFheGi2ZFJia3X_idTRQtWzbLR5mQ183GI81m-iXE=.98900081-6b3d-4f94-8e2e-133109c1d453@github.com>

On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) seems to be some JNI Checker warnings. I decided to resolve all the warnings in the debug agent and debugger tests that start with "in native method". This seems to have resolved [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) failure. There are still other JNI Checker warnings present that are not being dealt with at this time.
> 
> Testing:
> - [x] All tier1
> - [x] All tier2 svc tests
> - [x] All tier3 svc tests
> - [x] All tier4, which is where [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804) reproduced
> - [x] All tier5 svc tests

This pull request has now been integrated.

Changeset: 77cfcee8
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77cfcee8a1e571d32a1cf28926128edb97fcd696
Stats:     109 lines in 9 files changed: 64 ins; 24 del; 21 mod

8345422: Fix JNI Checker "in native method" warnings in the debug agent and debugger tests
8344804: Test serviceability/jdwp/AllModulesCommandTest.java times out after JNI check warning

Reviewed-by: amenkov, dholmes

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

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

From alanb at openjdk.org  Thu Dec  5 10:48:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 10:48:12 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util
Message-ID: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>

We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.

ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.

sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.

The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.

Testing: tier1-5

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22572/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22572&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345565
  Stats: 256 lines in 10 files changed: 0 ins; 251 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22572.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22572/head:pull/22572

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

From kevinw at openjdk.org  Thu Dec  5 11:33:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 5 Dec 2024 11:33:36 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util
In-Reply-To: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
Message-ID: <iunXHEWDxoFWI10NoY7AVc8Eu-Flp9_GItMISkcRF54=.138712c3-f584-4058-9af4-ad01fb340dc4@github.com>

On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
> 
> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
> 
> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
> 
> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
> 
> Testing: tier1-5

The java.management change/removal looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/22572#issuecomment-2520051019

From stuefe at openjdk.org  Thu Dec  5 14:35:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 14:35:43 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
Message-ID: <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>

On Mon, 2 Dec 2024 14:52:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello, @tstuefe , and thanks for your comments.  I'll address a few here while I work on the others.
>> I have changed the os-specific names to lowercase, but I don't think it makes them stand out more.  The square brackets were intended to do that.  Might I change this back?
>> 
>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
>> 
>> I will look at the META and CLASS entries and see if there are hidden properties that I can surface, or if there's another reason for so many entries.
>> 
>> [1] I had given a target architecture to the configure command, which turned on cross-compiles (which disables CDS archive building) even when building on the target platform.
>
> Hi @stooke !
> 
>> Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back?
> 
> Sure, if it looks worse. I just wanted to make sure we can cleanly distinguish NMT sections from OS sections.
> 
>> 
>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
> 
> Has nothing to do with CDS. The heap consists of committed and reserved areas. Committed areas have backing swap space allocated for them, and are accessible. Reserved areas have not and are generally not. API wise the difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and are generally allocated with PROT_NONE. 
> 
> So, the heap should show up with several neighboring sections, some committed, some just reserved. Similar how most of the stacks should show up with two entries, one for the writable stack, one for the guard page that is protected.
> 
> ---
> 
> 
> Simple test I did on MacOS with your patch: I reserve 1G of memory at startup, uncommitted (added to os::init_2)
> 
> 
>   if (UseNewCode) {
>     char* p = os::reserve_memory(G, false, mtInternal);
>     tty->print_cr("Pointer is %p", p);
>   }
> 
> 
> 
> vmmap shows:
> 
> 
> VM_ALLOCATE                 10ccb4000-14ccb4000    [  1.0G     0K     0K     0K] ---/rwx SM=NUL  
> 
> 
> so, looks good. 1GB, with all protection flags cleared. But System.map shows nothing for this address range.
> 
> 
> Now, I commit the second half of the range:
> 
> 
> 
>   if (UseNewCode) {
>     char* p = os::reserve_memory(G, false, mtInternal);
>     tty->print_cr("Pointer is %p", p);
>     bool b = os::commit_memory(p + (512 * M), 512 * M, false);
>     assert(b,"???");
>   }
> 
> 
> vmmap shows only the committed part now, omitting the still uncommitted first half. But it gets the protection flags right again (rw now):
> 
> 
> VM_ALLOCATE (reserved)      148000000-168000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)
> 
> 
> System.map shows nothing.
> 
> 
> What goes on? Is the OS lying to us? Do we have an error? Both vmmap and System.map seem to struggle, with vmmap being somewhat more correct.

> @tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free". As to the strange vmmap behaviour, I found that the two sections appeared in different places: the uncommitted spaces appeared in "==== Non-writable regions for process": `VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K 0K] ---/rwx SM=NUL ` and the committed spaces in "==== Writable regions for process": `VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) ` I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output. [vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)

Yes, this is better.

Metaspace sections look like this:


0x000130000000-0x000130010000                65536 rw-/rwx pvt            0  META 
0x000130010000-0x000130020000                65536 rw-/rwx pvt            0  META 
0x000130020000-0x000130400000              4063232 ---/rwx ---      0x20000  META 
0x000130400000-0x000130410000                65536 rw-/rwx pvt            0  META 
0x000130410000-0x000134000000             62849024 ---/rwx ---     0x410000  META 


A single 64MB space node. First three entries together are the initial 4MB chunk the boot class loader uses. Forth line, together with some space from the fifth line will belong to the next chunk of the next class loader.

Class space is still a bit weird:


0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
0x018001050000-0x018008000000            117112832 ---/rwx ---    0x1050000  CLASS 
0x018008000000-0x018010000000            134217728 ---/rwx ---            0  CLASS 
0x018010000000-0x018018000000            134217728 ---/rwx ---            0  CLASS 
0x018018000000-0x018020000000            134217728 ---/rwx ---            0  CLASS 
0x018020000000-0x018028000000            134217728 ---/rwx ---            0  CLASS 
0x018028000000-0x018030000000            134217728 ---/rwx ---            0  CLASS 
0x018030000000-0x018038000000            134217728 ---/rwx ---            0  CLASS 
0x018038000000-0x018040000000            134217728 ---/rwx ---            0  CLASS 
0x018040000000-0x018041000000             16777216 ---/rwx ---            0  CLASS 


Class space by default is 1GB, and that figures (all lines together), and the first two lines are the initial bootloader chunk of 256k. But following that, I would have expected a single line for the remaining uncommitted space, but it seems to report segments at a 128MB-aligned boundary.

I would have expected something like:


0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
0x018001050000-0x018041000000        1073414144 ---/rwx ---    0x1050000  CLASS 


Same can be seen with the JAVAHEAP:


0x000700000000-0x000708000000            134217728 rw-/rwx ---            0  JAVAHEAP 
0x000708000000-0x000710000000            134217728 rw-/rwx pvt            0  JAVAHEAP 
0x000710000000-0x000718000000            134217728 ---/rwx ---            0  JAVAHEAP 
0x000718000000-0x000720000000            134217728 ---/rwx ---            0  JAVAHEAP 
0x000720000000-0x000728000000            134217728 ---/rwx ---            0  JAVAHEAP 
0x000728000000-0x000730000000            134217728 ---/rwx ---            0  JAVAHEAP 
0x000730000000-0x000738000000            134217728 ---/rwx ---            0  JAVAHEAP 
0x000738000000-0x000740000000            134217728 ---/rwx ---            0  JAVAHEAP 
...


I first wondered whether we somehow cause this 128MB segmentation thing, but I don't think this is something we do. It is also appearant in malloc segments:


0x000148000000-0x000150000000            134217728 rw-/rwx pvt            0  [malloc_medium] 
0x000150000000-0x000158000000            134217728 rw-/rwx pvt            0  [malloc_medium] 
0x000158000000-0x000160000000            134217728 rw-/rwx pvt            0  [malloc_medium] 
0x000160000000-0x000168000000            134217728 rw-/rwx pvt            0  [malloc_medium] 


Do you understand this 128MB segmentation? Would it be possible to fold these into a single line, as we do on Linux? (On Linux, the kernel does it). 

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2520488961

From mullan at openjdk.org  Thu Dec  5 14:35:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Dec 2024 14:35:41 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util
In-Reply-To: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
Message-ID: <yeb-Nm1s3IVZF2IfJORDavXxU_4NDk5qXRpU_E3WXRc=.c5bfd0e8-d87a-4195-bb7d-cdadcb80911f@github.com>

On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
> 
> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
> 
> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
> 
> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
> 
> Testing: tier1-5

Couple of copyright updates missing, but otherwise looks fine to me.

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 1:

> 1: /*

copyright update

src/java.base/share/classes/sun/reflect/misc/MethodUtil.java line 1:

> 1: /*

copyright update.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22572#pullrequestreview-2481850956
PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871477976
PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871473062

From alanb at openjdk.org  Thu Dec  5 14:46:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 14:46:14 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
Message-ID: <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>

> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
> 
> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
> 
> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
> 
> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
> 
> Testing: tier1-5

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright header end dates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22572/files
  - new: https://git.openjdk.org/jdk/pull/22572/files/90530053..bd77ee66

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

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

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

From mullan at openjdk.org  Thu Dec  5 14:49:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 5 Dec 2024 14:49:37 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
Message-ID: <1g3wQr1OsDEjpCpYatMKNU9CKxOh3dy91bhXPnl4TKw=.b02044b8-0274-4636-8412-707ca2e47ede@github.com>

On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
>> 
>> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
>> 
>> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
>> 
>> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright header end dates

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22572#pullrequestreview-2481923349

From rriggs at openjdk.org  Thu Dec  5 14:49:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 5 Dec 2024 14:49:38 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
Message-ID: <Erkqn-YKfdFDbijessx6qH7WVLjT_OSNO3yrfGJ3d_U=.ef883afa-7fd5-4420-a991-888bf0798fad@github.com>

On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
>> 
>> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
>> 
>> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
>> 
>> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright header end dates

Thanks for those extra cleanups.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22572#pullrequestreview-2481925237

From liach at openjdk.org  Thu Dec  5 14:54:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 14:54:40 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
Message-ID: <1cdwjxZ3tG9W_g9ltiBMlA_SMIy8ZOKD4PYyooqyCRU=.31940d79-d87f-4ed4-bf32-f01cbc6d3418@github.com>

On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
>> 
>> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
>> 
>> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
>> 
>> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright header end dates

Marked as reviewed by liach (Reviewer).

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 138:

> 136:         assert genericDeclaration instanceof Class<?> ||
> 137:                 genericDeclaration instanceof Method ||
> 138:                 genericDeclaration instanceof Constructor : "Unexpected kind of GenericDeclaration";

Can remove this; check is already done in `make` factory.

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

PR Review: https://git.openjdk.org/jdk/pull/22572#pullrequestreview-2481936564
PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871523443

From liach at openjdk.org  Thu Dec  5 15:19:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 15:19:39 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <Az331LqUP9QlZ_maCftyEPF5OCu-7zUgPTtBPWh5yMQ=.fa5cf562-c2ef-49ce-a897-96153ea2665c@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
 <1cdwjxZ3tG9W_g9ltiBMlA_SMIy8ZOKD4PYyooqyCRU=.31940d79-d87f-4ed4-bf32-f01cbc6d3418@github.com>
 <Az331LqUP9QlZ_maCftyEPF5OCu-7zUgPTtBPWh5yMQ=.fa5cf562-c2ef-49ce-a897-96153ea2665c@github.com>
Message-ID: <b4DdRdoxbKRvi79iOugVGYvVUzICzaNtA0_Hmus55AM=.7b96cc25-0910-46ba-971c-abb299c80268@github.com>

On Thu, 5 Dec 2024 15:01:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 138:
>> 
>>> 136:         assert genericDeclaration instanceof Class<?> ||
>>> 137:                 genericDeclaration instanceof Method ||
>>> 138:                 genericDeclaration instanceof Constructor : "Unexpected kind of GenericDeclaration";
>> 
>> Can remove this; check is already done in `make` factory.
>
> I had hoped to keep the change focused on the removal of the left over ReflectUtil.checkPackageAccess, the else throw AssertionError was a surprise to see. So yes, I agree it can be removed but I'd prefer not touch it now, future work in this area can remove it.

Indeed, we should clean this up with things like MethodUtil.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871572144

From alanb at openjdk.org  Thu Dec  5 15:03:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 15:03:38 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <1cdwjxZ3tG9W_g9ltiBMlA_SMIy8ZOKD4PYyooqyCRU=.31940d79-d87f-4ed4-bf32-f01cbc6d3418@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
 <1cdwjxZ3tG9W_g9ltiBMlA_SMIy8ZOKD4PYyooqyCRU=.31940d79-d87f-4ed4-bf32-f01cbc6d3418@github.com>
Message-ID: <Az331LqUP9QlZ_maCftyEPF5OCu-7zUgPTtBPWh5yMQ=.fa5cf562-c2ef-49ce-a897-96153ea2665c@github.com>

On Thu, 5 Dec 2024 14:50:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright header end dates
>
> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 138:
> 
>> 136:         assert genericDeclaration instanceof Class<?> ||
>> 137:                 genericDeclaration instanceof Method ||
>> 138:                 genericDeclaration instanceof Constructor : "Unexpected kind of GenericDeclaration";
> 
> Can remove this; check is already done in `make` factory.

I had hoped to keep the change focused on the removal of the left over ReflectUtil.checkPackageAccess, the else throw AssertionError was a surprise to see. So yes, I agree it can be removed but I'd prefer not touch it now, future work in this area can remove it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871541980

From alanb at openjdk.org  Thu Dec  5 15:24:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 15:24:43 GMT
Subject: RFR: 8345565: Remove remaining SecurityManager motivated APIs from
 sun.reflect.util [v2]
In-Reply-To: <b4DdRdoxbKRvi79iOugVGYvVUzICzaNtA0_Hmus55AM=.7b96cc25-0910-46ba-971c-abb299c80268@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
 <4ENPdfiatInLTIGMRXkIg9egD6jYayHaYStj1yzAV2Q=.4d9567cb-e870-4f94-ab5d-56fc60e58fe3@github.com>
 <1cdwjxZ3tG9W_g9ltiBMlA_SMIy8ZOKD4PYyooqyCRU=.31940d79-d87f-4ed4-bf32-f01cbc6d3418@github.com>
 <Az331LqUP9QlZ_maCftyEPF5OCu-7zUgPTtBPWh5yMQ=.fa5cf562-c2ef-49ce-a897-96153ea2665c@github.com>
 <b4DdRdoxbKRvi79iOugVGYvVUzICzaNtA0_Hmus55AM=.7b96cc25-0910-46ba-971c-abb299c80268@github.com>
Message-ID: <05MajnIAnxKkGYnk-x6xOvPeR0Dmty93qpppYioeSSs=.54cd954b-e339-4e2c-a196-36d14cb041a8@github.com>

On Thu, 5 Dec 2024 15:16:46 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I had hoped to keep the change focused on the removal of the left over ReflectUtil.checkPackageAccess, the else throw AssertionError was a surprise to see. So yes, I agree it can be removed but I'd prefer not touch it now, future work in this area can remove it.
>
> Indeed, we should clean this up with things like MethodUtil.

MethodUtil is for APIs that do reflective stuff on behave of callers so not tied to the SM execution mode. That is for another time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871580656

From alanb at openjdk.org  Thu Dec  5 15:24:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 15:24:44 GMT
Subject: Integrated: 8345565: Remove remaining SecurityManager motivated APIs
 from sun.reflect.util
In-Reply-To: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
References: <fiwxM8vQgbopWDRqsUbSatuYvLgS5326DrjaBHlunDo=.d946c6aa-2cce-4e07-9b6a-bc4cf83b045a@github.com>
Message-ID: <FdnXDDntFzUF7GHY6mt08NqQuNr-xo8Kfm2HGrDKY3Y=.18e2402f-fa8f-4d24-8724-a8af86a81581@github.com>

On Thu, 5 Dec 2024 10:20:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
> 
> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
> 
> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
> 
> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: 691e6921
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/691e692149c105b4ca34aaaba779675b6bcc7c65
Stats:     258 lines in 10 files changed: 0 ins; 251 del; 7 mod

8345565: Remove remaining SecurityManager motivated APIs from sun.reflect.util

Reviewed-by: mullan, rriggs, liach

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

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

From stooke at openjdk.org  Thu Dec  5 15:43:41 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 15:43:41 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
 <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
Message-ID: <-8G62HrF3CBYmWkQasK4eieXG6PJu_RgSSH0WKA-7RY=.26402cb0-96c7-4a39-adeb-68f4ec9f4af4@github.com>

On Thu, 5 Dec 2024 14:32:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi @stooke !
>> 
>>> Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back?
>> 
>> Sure, if it looks worse. I just wanted to make sure we can cleanly distinguish NMT sections from OS sections.
>> 
>>> 
>>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
>> 
>> Has nothing to do with CDS. The heap consists of committed and reserved areas. Committed areas have backing swap space allocated for them, and are accessible. Reserved areas have not and are generally not. API wise the difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and are generally allocated with PROT_NONE. 
>> 
>> So, the heap should show up with several neighboring sections, some committed, some just reserved. Similar how most of the stacks should show up with two entries, one for the writable stack, one for the guard page that is protected.
>> 
>> ---
>> 
>> 
>> Simple test I did on MacOS with your patch: I reserve 1G of memory at startup, uncommitted (added to os::init_2)
>> 
>> 
>>   if (UseNewCode) {
>>     char* p = os::reserve_memory(G, false, mtInternal);
>>     tty->print_cr("Pointer is %p", p);
>>   }
>> 
>> 
>> 
>> vmmap shows:
>> 
>> 
>> VM_ALLOCATE                 10ccb4000-14ccb4000    [  1.0G     0K     0K     0K] ---/rwx SM=NUL  
>> 
>> 
>> so, looks good. 1GB, with all protection flags cleared. But System.map shows nothing for this address range.
>> 
>> 
>> Now, I commit the second half of the range:
>> 
>> 
>> 
>>   if (UseNewCode) {
>>     char* p = os::reserve_memory(G, false, mtInternal);
>>     tty->print_cr("Pointer is %p", p);
>>     bool b = os::commit_memory(p + (512 * M), 512 * M, false);
>>     assert(b,"???");
>>   }
>> 
>> 
>> vmmap shows only the committed part now, omitting the still uncommitted first half. But it gets the protection flags right again (rw now):
>> 
>> 
>> VM_ALLOCATE (reserved)      148000000-168000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)
>> 
>> 
>> System.map shows nothing.
>> 
>> 
>> What goes on? Is the OS lying to us? Do we have an error? Both vmmap and System.map seem to struggle, with vmmap being somewhat more correct.
>
>> @tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free". As to the strange vmmap behaviour, I found that the two sections appeared in different places: the uncommitted spaces appeared in "==== Non-writable regions for process": `VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K 0K] ---/rwx SM=NUL ` and the committed spaces in "==== Writable regions for process": `VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) ` I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output. [vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)
> 
> Yes, this is better.
> 
> Metaspace sections look like this:
> 
> 
> 0x000130000000-0x000130010000                65536 rw-/rwx pvt            0  META 
> 0x000130010000-0x000130020000                65536 rw-/rwx pvt            0  META 
> 0x000130020000-0x000130400000              4063232 ---/rwx ---      0x20000  META 
> 0x000130400000-0x000130410000                65536 rw-/rwx pvt            0  META 
> 0x000130410000-0x000134000000             62849024 ---/rwx ---     0x410000  META 
> 
> 
> A single 64MB space node. First three entries together are the initial 4MB chunk the boot class loader uses. Forth line, together with some space from the fifth line will belong to the next chunk of the next class loader.
> 
> Class space is still a bit weird:
> 
> 
> 0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
> 0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
> 0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
> 0x018001050000-0x018008000000            117112832 ---/rwx ---    0x1050000  CLASS 
> 0x018008000000-0x018010000000            134217728 ---/rwx ---            0  CLASS 
> 0x018010000000-0x018018000000            134217728 ---/rwx ---            0  CLASS 
> 0x018018000000-0x018020000000            134217728 ---/rwx ---            0  CLASS 
> 0x018020000000-0x018028000000            134217728 ---/rwx ---            0  CLASS 
> 0x018028000000-0x018030000000            134217728 ---/rwx ---            0  CLASS 
> 0x018030000000-0x018038000000            134217728 ---/rwx ---            0  CLASS 
> 0x018038000000-0x018040000000            134217728 ---/rwx ---            0  CLASS 
> 0x018040000000-0x018041000000             16777216 ---/rwx ---       ...

@tstuefe I ran an experiment with raw mmap, and there's no way to differentiate between one large allocation of 5*128MB and 5 smaller allocations of 128MB.  I _could_ add code to fold these, but we risk loosing information.

**I have found that the combination of mach_make_memory_entry_64() + mach_vm_map() (instead of using mmap(), which is just a compatibility layer on top of mach system calls) causes the kernel to treat the allocation as one region, and report it as such!  This may be a topic of a further PR**

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2520662304

From stuefe at openjdk.org  Thu Dec  5 16:06:38 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 16:06:38 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
 <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
Message-ID: <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>

On Thu, 5 Dec 2024 14:32:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi @stooke !
>> 
>>> Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back?
>> 
>> Sure, if it looks worse. I just wanted to make sure we can cleanly distinguish NMT sections from OS sections.
>> 
>>> 
>>> I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available.
>> 
>> Has nothing to do with CDS. The heap consists of committed and reserved areas. Committed areas have backing swap space allocated for them, and are accessible. Reserved areas have not and are generally not. API wise the difference is that Reserved sections set the MAP_NORESERVE flag for mmap, and are generally allocated with PROT_NONE. 
>> 
>> So, the heap should show up with several neighboring sections, some committed, some just reserved. Similar how most of the stacks should show up with two entries, one for the writable stack, one for the guard page that is protected.
>> 
>> ---
>> 
>> 
>> Simple test I did on MacOS with your patch: I reserve 1G of memory at startup, uncommitted (added to os::init_2)
>> 
>> 
>>   if (UseNewCode) {
>>     char* p = os::reserve_memory(G, false, mtInternal);
>>     tty->print_cr("Pointer is %p", p);
>>   }
>> 
>> 
>> 
>> vmmap shows:
>> 
>> 
>> VM_ALLOCATE                 10ccb4000-14ccb4000    [  1.0G     0K     0K     0K] ---/rwx SM=NUL  
>> 
>> 
>> so, looks good. 1GB, with all protection flags cleared. But System.map shows nothing for this address range.
>> 
>> 
>> Now, I commit the second half of the range:
>> 
>> 
>> 
>>   if (UseNewCode) {
>>     char* p = os::reserve_memory(G, false, mtInternal);
>>     tty->print_cr("Pointer is %p", p);
>>     bool b = os::commit_memory(p + (512 * M), 512 * M, false);
>>     assert(b,"???");
>>   }
>> 
>> 
>> vmmap shows only the committed part now, omitting the still uncommitted first half. But it gets the protection flags right again (rw now):
>> 
>> 
>> VM_ALLOCATE (reserved)      148000000-168000000    [512.0M     0K     0K     0K] rw-/rwx SM=NUL          reserved VM address space (unallocated)
>> 
>> 
>> System.map shows nothing.
>> 
>> 
>> What goes on? Is the OS lying to us? Do we have an error? Both vmmap and System.map seem to struggle, with vmmap being somewhat more correct.
>
>> @tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free". As to the strange vmmap behaviour, I found that the two sections appeared in different places: the uncommitted spaces appeared in "==== Non-writable regions for process": `VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K 0K] ---/rwx SM=NUL ` and the committed spaces in "==== Writable regions for process": `VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) ` I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output. [vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)
> 
> Yes, this is better.
> 
> Metaspace sections look like this:
> 
> 
> 0x000130000000-0x000130010000                65536 rw-/rwx pvt            0  META 
> 0x000130010000-0x000130020000                65536 rw-/rwx pvt            0  META 
> 0x000130020000-0x000130400000              4063232 ---/rwx ---      0x20000  META 
> 0x000130400000-0x000130410000                65536 rw-/rwx pvt            0  META 
> 0x000130410000-0x000134000000             62849024 ---/rwx ---     0x410000  META 
> 
> 
> A single 64MB space node. First three entries together are the initial 4MB chunk the boot class loader uses. Forth line, together with some space from the fifth line will belong to the next chunk of the next class loader.
> 
> Class space is still a bit weird:
> 
> 
> 0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
> 0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
> 0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
> 0x018001050000-0x018008000000            117112832 ---/rwx ---    0x1050000  CLASS 
> 0x018008000000-0x018010000000            134217728 ---/rwx ---            0  CLASS 
> 0x018010000000-0x018018000000            134217728 ---/rwx ---            0  CLASS 
> 0x018018000000-0x018020000000            134217728 ---/rwx ---            0  CLASS 
> 0x018020000000-0x018028000000            134217728 ---/rwx ---            0  CLASS 
> 0x018028000000-0x018030000000            134217728 ---/rwx ---            0  CLASS 
> 0x018030000000-0x018038000000            134217728 ---/rwx ---            0  CLASS 
> 0x018038000000-0x018040000000            134217728 ---/rwx ---            0  CLASS 
> 0x018040000000-0x018041000000             16777216 ---/rwx ---       ...

> @tstuefe I ran an experiment with raw mmap, and there's no way to differentiate between one large allocation of 5*128MB and 5 smaller allocations of 128MB. I _could_ add code to fold these, but we risk loosing information.

What information would we loose?

As it is now, the display is somewhat confusing. We did not allocate the heap with multiple mmap calls, each one of 128MB in size; we use a single mmap call.

If you want to close the work for now and leave this glitch for later, we can do this too.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2520776514

From stooke at openjdk.org  Thu Dec  5 16:50:44 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 16:50:44 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
 <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
 <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>
Message-ID: <T81sEzFL4atCxGVqCxNHM9gwPDcIr3V4RjW82RPbr3o=.da38e633-f092-4610-99f5-216432a667cf@github.com>

On Thu, 5 Dec 2024 16:04:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> @tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free". As to the strange vmmap behaviour, I found that the two sections appeared in different places: the uncommitted spaces appeared in "==== Non-writable regions for process": `VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K 0K] ---/rwx SM=NUL ` and the committed spaces in "==== Writable regions for process": `VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) ` I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output. [vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)
>> 
>> Yes, this is better.
>> 
>> Metaspace sections look like this:
>> 
>> 
>> 0x000130000000-0x000130010000                65536 rw-/rwx pvt            0  META 
>> 0x000130010000-0x000130020000                65536 rw-/rwx pvt            0  META 
>> 0x000130020000-0x000130400000              4063232 ---/rwx ---      0x20000  META 
>> 0x000130400000-0x000130410000                65536 rw-/rwx pvt            0  META 
>> 0x000130410000-0x000134000000             62849024 ---/rwx ---     0x410000  META 
>> 
>> 
>> A single 64MB space node. First three entries together are the initial 4MB chunk the boot class loader uses. Forth line, together with some space from the fifth line will belong to the next chunk of the next class loader.
>> 
>> Class space is still a bit weird:
>> 
>> 
>> 0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
>> 0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
>> 0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
>> 0x018001050000-0x018008000000            117112832 ---/rwx ---    0x1050000  CLASS 
>> 0x018008000000-0x018010000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018010000000-0x018018000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018018000000-0x018020000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018020000000-0x018028000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018028000000-0x018030000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018030000000-0x018038000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018038000000-0x018040000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018040...
>
>> @tstuefe I ran an experiment with raw mmap, and there's no way to differentiate between one large allocation of 5*128MB and 5 smaller allocations of 128MB. I _could_ add code to fold these, but we risk loosing information.
> 
> What information would we loose?
> 
> As it is now, the display is somewhat confusing. We did not allocate the heap with multiple mmap calls, each one of 128MB in size; we use a single mmap call.
> 
> If you want to close the work for now and leave this glitch for later, we can do this too.

@tstuefe if it's up to me, I would leave the folding for a quick later PR (in fact I would start it right after this one goes in).
I also would like to investigate the use of mach_make_memory_entry_64() which could be interesting on it's own.

Do you know how I can get the GitHub runner to start working?  It seems one of them is misconfigured.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2520899367

From stuefe at openjdk.org  Thu Dec  5 17:44:04 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 17:44:04 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
 <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
 <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>
Message-ID: <pUoyYSroU6TrSYbbWToKHAZiQNeE1ubbaZgiYVy63eM=.154a4ccd-1811-464f-ae39-c5160b816f93@github.com>

On Thu, 5 Dec 2024 16:04:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> @tstuefe I've look into your test, and I will modify the PR to display these regions - it was incorrectly identifying them as "free". As to the strange vmmap behaviour, I found that the two sections appeared in different places: the uncommitted spaces appeared in "==== Non-writable regions for process": `VM_ALLOCATE 300000000-320000000 [512.0M 0K 0K 0K] ---/rwx SM=NUL ` and the committed spaces in "==== Writable regions for process": `VM_ALLOCATE (reserved) 320000000-340000000 [512.0M 0K 0K 0K] rw-/rwx SM=NUL reserved VM address space (unallocated) ` I have made a few changes, track reserved and committed memory better, and uploaded an updated sample output. [vm_memory_map_89174.txt](https://github.com/user-attachments/files/18013640/vm_memory_map_89174.txt)
>> 
>> Yes, this is better.
>> 
>> Metaspace sections look like this:
>> 
>> 
>> 0x000130000000-0x000130010000                65536 rw-/rwx pvt            0  META 
>> 0x000130010000-0x000130020000                65536 rw-/rwx pvt            0  META 
>> 0x000130020000-0x000130400000              4063232 ---/rwx ---      0x20000  META 
>> 0x000130400000-0x000130410000                65536 rw-/rwx pvt            0  META 
>> 0x000130410000-0x000134000000             62849024 ---/rwx ---     0x410000  META 
>> 
>> 
>> A single 64MB space node. First three entries together are the initial 4MB chunk the boot class loader uses. Forth line, together with some space from the fifth line will belong to the next chunk of the next class loader.
>> 
>> Class space is still a bit weird:
>> 
>> 
>> 0x018001000000-0x018001010000                65536 rw-/rwx pvt            0  CLASS 
>> 0x018001010000-0x018001040000               196608 ---/rwx ---    0x1010000  CLASS 
>> 0x018001040000-0x018001050000                65536 rw-/rwx pvt            0  CLASS 
>> 0x018001050000-0x018008000000            117112832 ---/rwx ---    0x1050000  CLASS 
>> 0x018008000000-0x018010000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018010000000-0x018018000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018018000000-0x018020000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018020000000-0x018028000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018028000000-0x018030000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018030000000-0x018038000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018038000000-0x018040000000            134217728 ---/rwx ---            0  CLASS 
>> 0x018040...
>
>> @tstuefe I ran an experiment with raw mmap, and there's no way to differentiate between one large allocation of 5*128MB and 5 smaller allocations of 128MB. I _could_ add code to fold these, but we risk loosing information.
> 
> What information would we loose?
> 
> As it is now, the display is somewhat confusing. We did not allocate the heap with multiple mmap calls, each one of 128MB in size; we use a single mmap call.
> 
> If you want to close the work for now and leave this glitch for later, we can do this too.

> @tstuefe if it's up to me, I would leave the folding for a quick later PR (in fact I would start it right after this one goes in). I also would like to investigate the use of mach_make_memory_entry_64() which could be interesting on it's own.
> 
> Do you know how I can get the GitHub runner to start working? It seems one of them is misconfigured.

No idea, but it was broken for a while now, wasn't it? If you figure it out and fix it a lot of ppl would be thankful :)

Otherwise, since the code does not touch anything dangerous, I think its fine to check it in as long as the other platforms are green and you have executed the relevant test on MacOS for System.map and System.dump_map

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2521030368

From stuefe at openjdk.org  Thu Dec  5 17:49:44 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 17:49:44 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v11]
In-Reply-To: <cnqHOu3yELbruqjvj8-bZvN2azt_bjUAKqW6pndu77U=.8df72185-ec29-40d4-8a99-e7b5bab4de07@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <cnqHOu3yELbruqjvj8-bZvN2azt_bjUAKqW6pndu77U=.8df72185-ec29-40d4-8a99-e7b5bab4de07@github.com>
Message-ID: <9PTSAYD0TCY_T8QObH3qj75SDnfz1w8GRiVP9I_UivY=.4668885a-b77e-4530-907c-65f1f21b651e@github.com>

On Wed, 4 Dec 2024 20:20:16 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix trailing whitesdpae errors

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 99:

> 97:     if (valid_share_mode) {
> 98:       int share_mode = rinfo.pri_share_mode;
> 99:       out.print_raw(share_strings[share_mode - 1]);

this makes me nervous. Please do a bounds check beforehand. Assert is fine. Who knows if Apple changes the numeric definitions for SM_xxx

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 107:

> 105: 
> 106: #define X1(TAG, DESCR) X2(TAG, DESCR)
> 107: //#define X1(TAG) case VM_MEMORY_ ## TAG: return # TAG;

remnant?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1871824371
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1871820262

From stooke at openjdk.org  Thu Dec  5 18:37:23 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 18:37:23 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v12]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <0_973fcRtfj_ILGY2FhffWm-CxbZA2wWam4daMSOCSM=.bfa7718f-bfe9-4ab5-939c-df14bce58ef0@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  combine like 128MB regions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/07184546..c6c679a2

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

  Stats: 35 lines in 1 file changed: 28 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953

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

From stooke at openjdk.org  Thu Dec  5 18:45:59 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 18:45:59 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v13]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <hnzBt2vC1oUvd6dewSfRAMmH7PmJv-7hCA9Pe-2h7V4=.210705b1-49b0-406e-aa63-ad24ca332b39@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/c6c679a2..4e2ddedd

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

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

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

From stooke at openjdk.org  Thu Dec  5 18:45:59 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 18:45:59 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <pUoyYSroU6TrSYbbWToKHAZiQNeE1ubbaZgiYVy63eM=.154a4ccd-1811-464f-ae39-c5160b816f93@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
 <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>
 <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>
 <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com>
 <HENt2QvqwCMC3w9oUXlaJkef2n6Fxjm5yyMsQUzQaOU=.f82015ed-f4cb-419f-b9be-96d5431cf61f@github.com>
 <HoJzLOMujraHnZBk3fvrtJuHoAeauqHlIc6TYR8h2ws=.bdbc0483-7071-4194-9036-5608ef91a93d@github.com>
 <7kq9lfhwOBrPh3SWs4fItM-TTE4ASI0-NRSgRa12bTA=.e2b81568-a88f-4056-ab9d-6a76b5a0c2a4@github.com>
 <6H982xvc7wGz1p313njYSEH17Za45bAyJrxb0eozxQU=.69c8e62b-1b60-4ce2-a268-1fbb33610124@github.com>
 <pUoyYSroU6TrSYbbWToKHAZiQNeE1ubbaZgiYVy63eM=.154a4ccd-1811-464f-ae39-c5160b816f93@github.com>
Message-ID: <FdMMOW3x_WwE5scZcPiEC1vbkU5tu-THZvXW_0VSfms=.0e4a53d3-1ff9-43a5-acfd-ed078a965c67@github.com>

On Thu, 5 Dec 2024 17:41:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> @tstuefe I ran an experiment with raw mmap, and there's no way to differentiate between one large allocation of 5*128MB and 5 smaller allocations of 128MB. I _could_ add code to fold these, but we risk loosing information.
>> 
>> What information would we loose?
>> 
>> As it is now, the display is somewhat confusing. We did not allocate the heap with multiple mmap calls, each one of 128MB in size; we use a single mmap call.
>> 
>> If you want to close the work for now and leave this glitch for later, we can do this too.
>
>> @tstuefe if it's up to me, I would leave the folding for a quick later PR (in fact I would start it right after this one goes in). I also would like to investigate the use of mach_make_memory_entry_64() which could be interesting on it's own.
>> 
>> Do you know how I can get the GitHub runner to start working? It seems one of them is misconfigured.
> 
> No idea, but it was broken for a while now, wasn't it? If you figure it out and fix it a lot of ppl would be thankful :)
> 
> Otherwise, since the code does not touch anything dangerous, I think its fine to check it in as long as the other platforms are green and you have executed the relevant test on MacOS for System.map and System.dump_map

@tstuefe , I've actually added the combining code here, and reconfirmed that both the System.map and System.dump_map tests pass on my arm M2.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2521151800

From stooke at openjdk.org  Thu Dec  5 18:46:00 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 5 Dec 2024 18:46:00 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v11]
In-Reply-To: <9PTSAYD0TCY_T8QObH3qj75SDnfz1w8GRiVP9I_UivY=.4668885a-b77e-4530-907c-65f1f21b651e@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <cnqHOu3yELbruqjvj8-bZvN2azt_bjUAKqW6pndu77U=.8df72185-ec29-40d4-8a99-e7b5bab4de07@github.com>
 <9PTSAYD0TCY_T8QObH3qj75SDnfz1w8GRiVP9I_UivY=.4668885a-b77e-4530-907c-65f1f21b651e@github.com>
Message-ID: <D7p04SfzVK1PcAyShVYEBD3436gDD5lJvEuKeSWUQyY=.960bbc57-95c9-49dd-970f-70cc6118978a@github.com>

On Thu, 5 Dec 2024 17:45:06 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix trailing whitesdpae errors
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 99:
> 
>> 97:     if (valid_share_mode) {
>> 98:       int share_mode = rinfo.pri_share_mode;
>> 99:       out.print_raw(share_strings[share_mode - 1]);
> 
> this makes me nervous. Please do a bounds check beforehand. Assert is fine. Who knows if Apple changes the numeric definitions for SM_xxx

Done.

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 107:
> 
>> 105: 
>> 106: #define X1(TAG, DESCR) X2(TAG, DESCR)
>> 107: //#define X1(TAG) case VM_MEMORY_ ## TAG: return # TAG;
> 
> remnant?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1871914886
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1871915109

From schernyshev at openjdk.org  Thu Dec  5 20:05:56 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 5 Dec 2024 20:05:56 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>

> 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 to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - diverged after integration of JDK-8344177
   
   # Conflicts:
   #	src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java
 - update cgroup v1 in metrics
 - Apply suggestions from code review
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - updated test (path is reduced)
 - updated test (path is reduced)
 - adjust path suffix in cgroup (v1) version specific code, when root != cgroup
 - Merge branch 'master' into JDK-8343191
 - warn wenn ../ encountered, update path adjustment
 - Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
   
   Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
 - Merge branch 'master' into JDK-8343191
 - ... and 3 more: https://git.openjdk.org/jdk/compare/bd6d911c...2a7e9d82

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

Changes: https://git.openjdk.org/jdk/pull/21808/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=08
  Stats: 387 lines in 10 files changed: 345 ins; 4 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

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

From liach at openjdk.org  Thu Dec  5 20:44:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 20:44:59 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
 - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

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

Changes: https://git.openjdk.org/jdk/pull/22420/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=01
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420

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

From mchung at openjdk.org  Thu Dec  5 22:02:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 22:02:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

The change looks okay to me except `ParameterAnnotations.java`.   This task is part of JEP 484 and test-only.   It seems good to backport to 24.

test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:

> 641: 
> 642:         Task.Result result = new JavacTask(tb)
> 643:                 .processors(new TestAP())

I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

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

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483057967
PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872207964

From liach at openjdk.org  Thu Dec  5 22:29:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:29:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
Message-ID: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>

On Thu, 5 Dec 2024 21:54:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714
>
> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
> 
>> 641: 
>> 642:         Task.Result result = new JavacTask(tb)
>> 643:                 .processors(new TestAP())
> 
> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.

> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java

>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.

I should attach the exact error message:


test: testInnerClass
[DIRECT]:
- compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
- compiler.err.proc.no.explicit.annotation.processing.requested: T$I
2 errors
Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
toolbox.Task$TaskError: Task javac failed: rc=1
        at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
        at toolbox.JavacTask.run(JavacTask.java:381)
        at toolbox.AbstractTask.run(AbstractTask.java:102)
        at toolbox.JavacTask.run(JavacTask.java:52)
        at toolbox.JavacTask.run(JavacTask.java:321)
        at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
        at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at toolbox.TestRunner.runTests(TestRunner.java:91)
        at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
        at ParameterAnnotations.main(ParameterAnnotations.java:73)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1447)


Same for all 5 tests in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872240998

From liach at openjdk.org  Thu Dec  5 22:39:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:39:38 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
 <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
Message-ID: <YGI23OMLvPmZm9gfhhWUYJBV33J8XNfmEgNxr_BqDNc=.b0bb0f88-7494-433e-81f7-bddfc90039aa@github.com>

On Thu, 5 Dec 2024 22:26:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
>> 
>>> 641: 
>>> 642:         Task.Result result = new JavacTask(tb)
>>> 643:                 .processors(new TestAP())
>> 
>> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.
>
> It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.
> 
>> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> I should attach the exact error message:
> 
> 
> test: testInnerClass
> [DIRECT]:
> - compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
> - compiler.err.proc.no.explicit.annotation.processing.requested: T$I
> 2 errors
> Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
> toolbox.Task$TaskError: Task javac failed: rc=1
>         at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
>         at toolbox.JavacTask.run(JavacTask.java:381)
>         at toolbox.AbstractTask.run(AbstractTask.java:102)
>         at toolbox.JavacTask.run(JavacTask.java:52)
>         at toolbox.JavacTask.run(JavacTask.java:321)
>         at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
>         at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at toolbox.TestRunner.runTests(TestRunner.java:91)
>         at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
>         at ParameterAnnotations.main(ParameterAnnotations.java:73)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>         at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> 
> Same for all 5 tests in this file.

Filed https://bugs.openjdk.org/browse/JDK-8345622. There is no similar issues that happen as a conjunction of preview and annotation processing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872252558

From mchung at openjdk.org  Thu Dec  5 23:04:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 23:04:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <maLFwsbZ7sM2p1lT95sryUOcy-Np0ltOALkqtOi2V14=.50a73592-c116-467e-8b01-de69d690acc4@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for filing the issue to follow up.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483183112

From asotona at openjdk.org  Fri Dec  6 07:01:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Dec 2024 07:01:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <cYKI7KfuddHlzINClbgrqWQuLJPTw5rYBUurMV61Gbg=.a84e6ec5-b489-44be-ad12-65bbb954aab8@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Looks good to me, thanks.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483795644

From sgehwolf at openjdk.org  Fri Dec  6 09:57:43 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 6 Dec 2024 09:57:43 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
Message-ID: <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>

On Thu, 5 Dec 2024 20:05:56 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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - diverged after integration of JDK-8344177
>    
>    # Conflicts:
>    #	src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java
>  - update cgroup v1 in metrics
>  - Apply suggestions from code review
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - updated test (path is reduced)
>  - updated test (path is reduced)
>  - adjust path suffix in cgroup (v1) version specific code, when root != cgroup
>  - Merge branch 'master' into JDK-8343191
>  - warn wenn ../ encountered, update path adjustment
>  - Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
>    
>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>  - Merge branch 'master' into JDK-8343191
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/bd6d911c...2a7e9d82

FYI: I'll try to test and review this more thoroughly next week.

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322:

> 320:     } else {
> 321:       log_warning(os, container)("Cgroup cpu/memory controller path includes '../', detected limits won't be accurate");
> 322:     }

Please move this warning to `CgroupUtil::adjust_controller` and abort the adjustment, we don't need to issue this warning multiple times, and we'd not be able to adjust it to a path that will work. Showing the warning once should be sufficient. We shouldn't see this path in any non-moved scenarios. It would perhaps help if we included some detail why this warning is being shown. I suggest:

```cgroup controller path seems to have moved (includes '.../'), detected limits won't be accurate```

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

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2484225572
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1872956609

From liach at openjdk.org  Fri Dec  6 14:27:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:46 GMT
Subject: Integrated: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <lC5dc_Tdirtuqzeo_Owzx7FAERGLPn3zxVToCnmFrVc=.37555c56-eae5-4674-812f-cf8c4c666c16@github.com>

On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

This pull request has now been integrated.

Changeset: 49664195
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/496641955041c5e48359e6256a4a61812653d900
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung, asotona

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

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

From liach at openjdk.org  Fri Dec  6 14:27:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <NFMYqK-YAR0M4ogdKPBJCDErb0InxSmKB1-4xAwM4m4=.b208051b-f553-41e3-b365-6fe0b48f4e68@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523362333

From liach at openjdk.org  Fri Dec  6 15:08:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:08:47 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <UbEObYZrmrSyDOgIKSYDiGuI4DJ5xs-oooevsmtRw3Q=.e2fbe36e-0d43-4ab1-9044-2a203019ffaa@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

>From internal discussion, this task is logically associated with the finalization of ClassFile API and is best done for the same release 24.

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

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523450991

From liach at openjdk.org  Fri Dec  6 15:17:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:17:26 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
Message-ID: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>

Hi all,

This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.

The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.

Thanks!

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

Commit messages:
 - Backport 496641955041c5e48359e6256a4a61812653d900

Changes: https://git.openjdk.org/jdk/pull/22607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334733
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22607/head:pull/22607

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

From duke at openjdk.org  Fri Dec  6 17:17:50 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 6 Dec 2024 17:17:50 GMT
Subject: RFR: 8345684: Prevent NPE in
 OperatingSystemImpl#isCpuSetSameAsHostCpuSet
Message-ID: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>

The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.

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

Commit messages:
 - 8345684: Prevent NPE in OperatingSystemImpl#isCpuSetSameAsHostCpuSet

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

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

From rriggs at openjdk.org  Fri Dec  6 17:47:37 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 6 Dec 2024 17:47:37 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
In-Reply-To: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
Message-ID: <eQnJ9cgljxgy-6z4b8FZUaK41LHbapGvyyu3H0DRibg=.a86f8576-6492-4401-8dea-8272474fde43@github.com>

On Fri, 6 Dec 2024 17:05:42 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.

src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 278:

> 276:     private boolean isCpuSetSameAsHostCpuSet() {
> 277:         if (containerMetrics != null) {
> 278:             int[] cpuSetCpus = containerMetrics.getCpuSetCpus();

Might be worth a comment about the volatility of getCpuSetCpus() to head off someone changing it back.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22611#discussion_r1873771463

From duke at openjdk.org  Fri Dec  6 18:02:53 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 6 Dec 2024 18:02:53 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
Message-ID: <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>

> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.

Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22611/files
  - new: https://git.openjdk.org/jdk/pull/22611/files/f7a442b3..30d1b03b

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

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

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

From duke at openjdk.org  Fri Dec  6 18:02:54 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 6 Dec 2024 18:02:54 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <eQnJ9cgljxgy-6z4b8FZUaK41LHbapGvyyu3H0DRibg=.a86f8576-6492-4401-8dea-8272474fde43@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <eQnJ9cgljxgy-6z4b8FZUaK41LHbapGvyyu3H0DRibg=.a86f8576-6492-4401-8dea-8272474fde43@github.com>
Message-ID: <0WWkp1KLx2eVKfbENtoFYncVxfvWKtGFk5Q8crhSXWs=.0e904b21-050e-4220-ad3f-849b8ed2b2ba@github.com>

On Fri, 6 Dec 2024 17:45:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java line 278:
> 
>> 276:     private boolean isCpuSetSameAsHostCpuSet() {
>> 277:         if (containerMetrics != null) {
>> 278:             int[] cpuSetCpus = containerMetrics.getCpuSetCpus();
> 
> Might be worth a comment about the volatility of getCpuSetCpus() to head off someone changing it back.

I added a comment explaining both the volatility and the potential cost.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22611#discussion_r1873792776

From coleenp at openjdk.org  Fri Dec  6 21:39:47 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Dec 2024 21:39:47 GMT
Subject: RFR: 8344922: Redefinition verifies the new klass when verification is
 disabled
Message-ID: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>

This change only verifies redefined classes if Verification is enabled.  BytecodeVerificationRemote will be false for verification turned off.  If someone turns it off but BytecodeVerificationLocal on (which is non-sensical), the argument processing code will fix that up.  So all this needs to do is check for BytecodeVerifificationRemote for -Xverify:none (which is a deprecated option).


  // Treat the odd case where local verification is enabled but remote
  // verification is not as if both were enabled.
  if (BytecodeVerificationLocal && !BytecodeVerificationRemote) {
    log_info(verification)("Turning on remote verification because local verification is on");
    FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
  }


Tested with runtime/verifier, jck vm and tier1-4 (in progress), and the new test case.

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

Commit messages:
 - 8344922: Redefinition verifies the new klass when verification is disabled

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

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

From coleenp at openjdk.org  Fri Dec  6 22:06:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Dec 2024 22:06:11 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
Message-ID: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>

This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.

Tested with jck:vm and tier1-4.

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

Commit messages:
 - 8345678: compute_modifiers should not be in create_mirror

Changes: https://git.openjdk.org/jdk/pull/22618/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345678
  Stats: 39 lines in 8 files changed: 19 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

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

From cjplummer at openjdk.org  Fri Dec  6 22:32:46 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 6 Dec 2024 22:32:46 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with
 JTREG_TEST_THREAD_FACTORY=Virtual.
Message-ID: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>

This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.

Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.

Testing:

- [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
- [ ] tier1
- [ ] tier2 svc
- [ ] tier5 svc

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

Commit messages:
 - Use VThreadPinner to make sure virtual threads are mounted when StopThread is called.

Changes: https://git.openjdk.org/jdk/pull/22620/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22620&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338714
  Stats: 26 lines in 3 files changed: 15 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22620.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22620/head:pull/22620

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

From stooke at openjdk.org  Fri Dec  6 22:55:22 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Fri, 6 Dec 2024 22:55:22 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v14]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <EdtR-1kRokz1nCbDySun_TIaamNXLE6HnqTwg_wNVb8=.69d7a297-a0d4-4bdd-b54b-667dfc0df732@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  add constant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/4e2ddedd..7b7c9665

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

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

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

From alanb at openjdk.org  Sat Dec  7 07:36:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 7 Dec 2024 07:36:37 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
Message-ID: <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>

On Fri, 6 Dec 2024 22:28:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
> 
> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
> 
> Testing:
> 
> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
> - [ ] tier1
> - [ ] tier2 svc
> - [ ] tier5 svc

test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 166:

> 164:     }
> 165: 
> 166:     public void run1() {

It might be a bit clear to rename run1 to runPinned (avoids run and run1).

test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 142:

> 140:             /* Some jdb tests need java.library.path setup for native libraries. */
> 141:             String libpath = System.getProperty("java.library.path");
> 142:             args.add("-R-Djava.library.path=" + libpath);

Good, I wasn't sure how this inherit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1874351813
PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1874351861

From cjplummer at openjdk.org  Sat Dec  7 08:00:46 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 7 Dec 2024 08:00:46 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
Message-ID: <mvmo336oAh-plyjIkFzvqW-yZjQDkA5sjLh-atbxiBk=.b0be0c0f-013f-42bd-94ca-4e6b983a2f80@github.com>

On Sat, 7 Dec 2024 07:33:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
>> 
>> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
>> 
>> Testing:
>> 
>> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
>> - [ ] tier1
>> - [ ] tier2 svc
>> - [ ] tier5 svc
>
> test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java line 166:
> 
>> 164:     }
>> 165: 
>> 166:     public void run1() {
> 
> It might be a bit clear to rename run1 to runPinned (avoids run and run1).

It also needs to support test runs with platforms threads. See how `run()` checks if it is running in virtual thread mode or not. Either way it calls `run()`, but in the virtual thread case it does so using VThreadPinner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1874356911

From stuefe at openjdk.org  Sat Dec  7 08:40:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 7 Dec 2024 08:40:41 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v12]
In-Reply-To: <0_973fcRtfj_ILGY2FhffWm-CxbZA2wWam4daMSOCSM=.bfa7718f-bfe9-4ab5-939c-df14bce58ef0@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <0_973fcRtfj_ILGY2FhffWm-CxbZA2wWam4daMSOCSM=.bfa7718f-bfe9-4ab5-939c-df14bce58ef0@github.com>
Message-ID: <MAou_BIuFTxr4orOG2OTjFtr-aCNCHkVvn9uROmG9rQ=.d73aa835-66df-4cc4-b8f7-d8c9bfd08a44@github.com>

On Thu, 5 Dec 2024 18:37:23 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   combine like 128MB regions

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 97:

> 95:       _file_name.print_raw(mem_info.prp_vip.vip_path);
> 96:     }
> 97:     /* proc_regionfilename() seems to give bad results, so we don't try to use it here. */

We use // in cpp for most cases

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 113:

> 111:       "cow", "pvt", "---", "shr", "tsh", "p/a", "s/a", "lpg"
> 112:     };
> 113:     assert(SM_COW == 1 && SM_LARGE_PAGE == 8, "share_mode contants are out of range");

Suggestion:

    assert(SM_COW == 1 && SM_LARGE_PAGE == (sizeof(share_strings)/sizeof(share_strings[0]), "share_mode contants are out of range"); // the +1 offset is intentional, see below

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1874370759
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1874370994

From lmesnik at openjdk.org  Sat Dec  7 17:58:39 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 7 Dec 2024 17:58:39 GMT
Subject: RFR: 8305010: Test
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
 timed out: thread not suspended
In-Reply-To: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
References: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
Message-ID: <m4_QZI-0JsCEx436SlFxDPhyvnMj1EgMFUw0d1EsVCw=.350173e9-d921-4ea9-8c6c-b771f64a50a2@github.com>

On Wed, 4 Dec 2024 03:07:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and agent thread:
> The callbacks increments event counter and then do self-suspend;
> Agent thread waits when expected number of events is received, then performs verification and resumes the thread, but expected counter value does not mean the threads are suspended.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22532#pullrequestreview-2486662291

From alshranehajr at gmail.com  Sun Dec  8 00:33:44 2024
From: alshranehajr at gmail.com (Hajr AlShrane)
Date: Sun, 8 Dec 2024 03:33:44 +0300
Subject: RFR(XS) for PeriodicTask_lock cleanup (8072439)
Message-ID: <CAPu1=BVJp7mNbnA1Ag-cevB9GLO82pJA2YsDX2V1AM-HdjQ5pg@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241208/f3358505/attachment-0001.htm>

From alshranehajr at gmail.com  Sun Dec  8 00:35:11 2024
From: alshranehajr at gmail.com (Hajr AlShrane)
Date: Sun, 8 Dec 2024 03:35:11 +0300
Subject: RFR (S) : 8073607 : add trace events for inlining
Message-ID: <CAPu1=BX3dsDhcQGwk7JssKfADd31xtfD2yqxWSibVYcoMiY3iQ@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241208/670ba7e8/attachment.htm>

From dholmes at openjdk.org  Mon Dec  9 02:11:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 02:11:39 GMT
Subject: RFR: 8344922: Redefinition verifies the new klass when
 verification is disabled
In-Reply-To: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
References: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
Message-ID: <B_qrubLR9TMKbQb8Vi9qtMkegbvCCixHN1_K7nvWGOE=.08add72b-da11-43a0-98c4-c9f1b690a0c3@github.com>

On Fri, 6 Dec 2024 21:34:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change only verifies redefined classes if Verification is enabled.  BytecodeVerificationRemote will be false for verification turned off.  If someone turns it off but BytecodeVerificationLocal on (which is non-sensical), the argument processing code will fix that up.  So all this needs to do is check for BytecodeVerifificationRemote for -Xverify:none (which is a deprecated option).
> 
> 
>   // Treat the odd case where local verification is enabled but remote
>   // verification is not as if both were enabled.
>   if (BytecodeVerificationLocal && !BytecodeVerificationRemote) {
>     log_info(verification)("Turning on remote verification because local verification is on");
>     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>   }
> 
> 
> Tested with runtime/verifier, jck vm and tier1-4 (in progress), and the new test case.

src/hotspot/share/classfile/verifier.cpp line 137:

> 135:   return (should_verify_class &&
> 136:     // Override parameter (return false) if -Xverify:none
> 137:     BytecodeVerificationRemote &&

Sorry but I don't understand why the correct value for `should_verify` doesn't filter through from `Verifier::should_verify_for`??? Seems to me that is the only place where we should explicitly check the verification flags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22617#discussion_r1875179302

From dholmes at openjdk.org  Mon Dec  9 04:31:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:31:38 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

This seems reasonable, but I wonder if we can simplify things further for arrays - see below.

Future RFE: I also think we need to cleanup terminology i.e. "modifier flags" versus "access flags".

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 1119:

> 1117:   // to support Class.getModifiers().  Instance classes recalculate
> 1118:   // the cached flags after the class file is parsed, but before the
> 1119:   // class is put into the system dictionary.

Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.

src/hotspot/share/oops/typeArrayKlass.hpp line 76:

> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
> 75: 
> 76:   // jvm support

"jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?

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

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2487697138
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875323314
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875322865

From dholmes at openjdk.org  Mon Dec  9 04:39:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:39:38 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
Message-ID: <ReRmrfi2CTJ2qH1AOs6bl9E6buhr1vy6q6g63uQtmDA=.8d584fba-e507-4e39-a7f9-80bfbc6acf86@github.com>

On Fri, 6 Dec 2024 18:02:53 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

LGTM.

Aside: from a Java API design perspective I think these container API's should be returning empty arrays not null

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22611#pullrequestreview-2487712607

From kevinw at openjdk.org  Mon Dec  9 09:04:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 09:04:37 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
Message-ID: <6QVUUCx4lN8OQtLHhtTW9Ey71poRcxB1wYTxEimBbwg=.9fb698f4-8cbc-4a92-bd99-75483904bb60@github.com>

On Fri, 6 Dec 2024 18:02:53 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Looks good, thanks 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22611#pullrequestreview-2488163974

From duke at openjdk.org  Mon Dec  9 09:31:37 2024
From: duke at openjdk.org (duke)
Date: Mon, 9 Dec 2024 09:31:37 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
Message-ID: <O3Gvn-uOazHaVx9ovPgpWBT6AnrncEP11VGr7siNBUU=.38188aa2-e097-4351-9b93-8903b7b178be@github.com>

On Fri, 6 Dec 2024 18:02:53 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

@fmeum 
Your change (at version 30d1b03b5ef6d4c1de72ef02ce8a94f98eec3a66) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527385393

From kevinw at openjdk.org  Mon Dec  9 09:45:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 09:45:37 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v2]
In-Reply-To: <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <HzIumbGan-o104heXhYGkbu1PVPYxpbqQ3K66CAjhZc=.270f63c8-71dd-4eae-8440-605ee9055549@github.com>
Message-ID: <ODXrgsOlOx92gVnMyPxd-yi9g7BteEk0YDNbAwQ2T7g=.b809381d-9d8e-4999-b3aa-2d58d947fa20@github.com>

On Fri, 6 Dec 2024 18:02:53 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Hi, 
This looks fine, I'm sure it's ok to proceed without waiting for a re-review from Roger about the comment.

It would be good to see the "Checks" tab show more than just jcheck.
Looks like this needs to be enabled in the personal fork.
https://wiki.openjdk.org/display/SKARA/Testing

Then we get some basic builds and tests done for us, and can go ahead with (even more) confidence!

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527418181

From duke at openjdk.org  Mon Dec  9 10:07:14 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 9 Dec 2024 10:07:14 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
Message-ID: <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>

> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.

Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:

  Empty commit to trigger CI checks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22611/files
  - new: https://git.openjdk.org/jdk/pull/22611/files/30d1b03b..0364f6b5

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

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

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

From kevinw at openjdk.org  Mon Dec  9 10:35:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 10:35:38 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
Message-ID: <KRLF1Sq1wNho50yu53B8CRMeJK1q-kqWYZSNY9w5MV8=.9d6caecc-149f-48b1-91a6-63f4063f92dd@github.com>

On Mon, 9 Dec 2024 10:07:14 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty commit to trigger CI checks

That's great.  As the sponsor label has gone, when these few tests finish I think you'll need to say /integrate again then I can sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527536154

From sgehwolf at openjdk.org  Mon Dec  9 10:49:38 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Dec 2024 10:49:38 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
Message-ID: <w1YVIIckcg0nkGzgmlgHLNoVLwBKEmufodjxcBLbnh0=.b813d0f3-6fe0-4ede-a5fa-39819f513c24@github.com>

On Mon, 9 Dec 2024 10:07:14 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty commit to trigger CI checks

LGTM

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22611#pullrequestreview-2488428790

From duke at openjdk.org  Mon Dec  9 11:54:38 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 9 Dec 2024 11:54:38 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
Message-ID: <w_h-Z1zAUh-hOwrwPBPNKsax1bUlL-KYYCWmE4LtdxY=.a905a08b-d97a-4d83-9e0f-ff2c5b30bdf3@github.com>

On Mon, 9 Dec 2024 10:07:14 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty commit to trigger CI checks

`test (hs/tier1 compiler not-xcomp)` fails on all platforms, is this expected?

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527706075

From kevinw at openjdk.org  Mon Dec  9 12:10:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 12:10:38 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
Message-ID: <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>

On Mon, 9 Dec 2024 10:07:14 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Empty commit to trigger CI checks

I think we can consider that failure some annoying noise.  It's not expected, but this Java-only change isn't causing it, other builds are fine, we should proceed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527739227

From duke at openjdk.org  Mon Dec  9 12:17:43 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 9 Dec 2024 12:17:43 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
 <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
Message-ID: <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>

On Mon, 9 Dec 2024 12:07:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Empty commit to trigger CI checks
>
> I think we can consider that failure some annoying noise.  It's not expected, but this Java-only change isn't causing it, other builds are fine, we should proceed.

@kevinjwalls Thanks! Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527763061

From ihse at openjdk.org  Mon Dec  9 12:17:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:17:44 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files where
 it was missed
Message-ID: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345795: Update copyright year to 2024 for hotspot in files where it was missed

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

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

From duke at openjdk.org  Mon Dec  9 12:17:44 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 9 Dec 2024 12:17:44 GMT
Subject: Integrated: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws
 NPE
In-Reply-To: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
Message-ID: <6XFbbLsKn_7bGo5nqYJ9H9RgBdbT8kf-o7ot-xV_6CM=.e479cd97-642e-4979-9420-1f16da43c3b5@github.com>

On Fri, 6 Dec 2024 17:05:42 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> The return value of Metrics#getCpuSetCpus may change over time, including from non-null to null across the two calls in this method.

This pull request has now been integrated.

Changeset: d7ef3ac0
Author:    Fabian Meumertzheim <fabian at meumertzhe.im>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7ef3ac0b7e677c4901c69ad4361b5de8408e8d3
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE

Reviewed-by: dholmes, kevinw, sgehwolf

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

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

From sgehwolf at openjdk.org  Mon Dec  9 12:29:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Dec 2024 12:29:48 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
 <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
 <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>
Message-ID: <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>

On Mon, 9 Dec 2024 12:14:32 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?

Please see https://github.com/openjdk/jdk21u-dev?tab=readme-ov-file#welcome-to-openjdk-21-updates for the process.

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527790319

From ihse at openjdk.org  Mon Dec  9 12:34:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:34:53 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed
Message-ID: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345799: Update copyright year to 2024 for core-libs in files where it was missed

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

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

From duke at openjdk.org  Mon Dec  9 12:36:46 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 9 Dec 2024 12:36:46 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
 <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
 <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>
 <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>
Message-ID: <OdgHlaGgt5sQCYIbFq-GsMbUDH7kU6m23n0CW82ovTw=.c76255b8-9449-4f5d-a3ab-a32a3b8fb774@github.com>

On Mon, 9 Dec 2024 12:27:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @kevinjwalls Thanks! Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?
>
>> Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?
> 
> Please see https://github.com/openjdk/jdk21u-dev?tab=readme-ov-file#welcome-to-openjdk-21-updates for the process.

@jerboaa It looks like I would need to be at least an *Author* to follow these instructions. Since this is my second merged PR to the OpenJDK, could I become one?

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527806218

From ihse at openjdk.org  Mon Dec  9 12:41:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:41:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

  Add more hotspot files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0605277d..0166c68e

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

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

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

From stooke at openjdk.org  Mon Dec  9 12:46:43 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 9 Dec 2024 12:46:43 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v12]
In-Reply-To: <MAou_BIuFTxr4orOG2OTjFtr-aCNCHkVvn9uROmG9rQ=.d73aa835-66df-4cc4-b8f7-d8c9bfd08a44@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <0_973fcRtfj_ILGY2FhffWm-CxbZA2wWam4daMSOCSM=.bfa7718f-bfe9-4ab5-939c-df14bce58ef0@github.com>
 <MAou_BIuFTxr4orOG2OTjFtr-aCNCHkVvn9uROmG9rQ=.d73aa835-66df-4cc4-b8f7-d8c9bfd08a44@github.com>
Message-ID: <S8Qcus-K0G0P89MoqsEUUzsiJUKtsek67BooSmFN_-M=.1c8a3753-3885-4998-861e-a875ff94aced@github.com>

On Sat, 7 Dec 2024 08:34:45 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   combine like 128MB regions
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 97:
> 
>> 95:       _file_name.print_raw(mem_info.prp_vip.vip_path);
>> 96:     }
>> 97:     /* proc_regionfilename() seems to give bad results, so we don't try to use it here. */
> 
> We use // in cpp for most cases

done.

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 113:
> 
>> 111:       "cow", "pvt", "---", "shr", "tsh", "p/a", "s/a", "lpg"
>> 112:     };
>> 113:     assert(SM_COW == 1 && SM_LARGE_PAGE == 8, "share_mode contants are out of range");
> 
> Suggestion:
> 
>     assert(SM_COW == 1 && SM_LARGE_PAGE == (sizeof(share_strings)/sizeof(share_strings[0]), "share_mode contants are out of range"); // the +1 offset is intentional, see below

done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1875923602
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1875924001

From ihse at openjdk.org  Mon Dec  9 12:48:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:48:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <QAwIZoxKKlbCIi_y4S8m9-u90W07cOngKe20_eEa7i8=.e9705ec8-2461-4805-80c5-a59a411f773e@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

Apologies for the force push; I accidentally pushed a commit that belonged to another branch here, and I just rolled back that commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2527832604

From ihse at openjdk.org  Mon Dec  9 12:52:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:52:16 GMT
Subject: RFR: 8345800: Update copyright year to 2024 for serviceability in
 files where it was missed
Message-ID: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345800: Update copyright year to 2024 for serviceability in files where it was missed

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

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

From sgehwolf at openjdk.org  Mon Dec  9 13:02:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Dec 2024 13:02:44 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
 <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
 <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>
 <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>
Message-ID: <FYBI7Jz5WtQqmdW_NO6cBkfU0RfZlaM_FrEzwKWNxAA=.e5dbea1d-2cd5-415e-9dcb-045278acb299@github.com>

On Mon, 9 Dec 2024 12:27:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @kevinjwalls Thanks! Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?
>
>> Apologies in advance if this is not the right process, but could this be cherry-picked into JDK 21?
> 
> Please see https://github.com/openjdk/jdk21u-dev?tab=readme-ov-file#welcome-to-openjdk-21-updates for the process.

> @jerboaa It looks like I would need to be at least an _Author_ to follow these instructions. Since this is my second merged PR to the OpenJDK, could I become one?

For the skara bot command, yes. For manual contribution, no. See https://wiki.openjdk.org/display/JDKUpdates/How+to+contribute+or+backport+a+fix

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527863019

From ihse at openjdk.org  Mon Dec  9 13:03:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:03:06 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

  Add more core-libs files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/e7cfe0f7..8e040c3a

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

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

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

From coleenp at openjdk.org  Mon Dec  9 13:05:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:05:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
Message-ID: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>

On Mon, 9 Dec 2024 04:22:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1119:
> 
>> 1117:   // to support Class.getModifiers().  Instance classes recalculate
>> 1118:   // the cached flags after the class file is parsed, but before the
>> 1119:   // class is put into the system dictionary.
> 
> Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.

I thought the comment was referring to this code below that recalculates the modifier flags.  Don't know why system dictionary was called out though.

> src/hotspot/share/oops/typeArrayKlass.hpp line 76:
> 
>> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
>> 75: 
>> 76:   // jvm support
> 
> "jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?

ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875946187
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875948835

From sgehwolf at openjdk.org  Mon Dec  9 13:05:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Dec 2024 13:05:44 GMT
Subject: RFR: 8345684: OperatingSystemMXBean.getSystemCpuLoad() throws NPE
 [v3]
In-Reply-To: <FYBI7Jz5WtQqmdW_NO6cBkfU0RfZlaM_FrEzwKWNxAA=.e5dbea1d-2cd5-415e-9dcb-045278acb299@github.com>
References: <rQPCjO4-FGHvQz8NJ2rlTNbp3XfrxbH7SOJ5aHnDSNI=.33109496-d70a-45b0-b733-dae684b5c5a5@github.com>
 <NfkLmJuUXsyLU1GQJwreiXEg_1l7wzsJpvcatcCAhbk=.ac687ad3-c64b-41df-8f18-db27cd768249@github.com>
 <Pzf8lrBR5HUA56AvmBWywML4NDTiTN-7DIW8wPE9qqA=.e59bc8a4-546c-4efa-9776-39087c682ed8@github.com>
 <A1AHx4beBeLLYVEgzX8JyTAx-GqPUjfU3Hb_08JL7u8=.2c0523eb-d72e-4c08-a02e-ff63692f0e9f@github.com>
 <Lb3Y6rZDVtQbyIB0To-JDJlufZG3SjwtOZojwdl3c9c=.60e94432-5745-4097-a952-8ab516519c1b@github.com>
 <FYBI7Jz5WtQqmdW_NO6cBkfU0RfZlaM_FrEzwKWNxAA=.e5dbea1d-2cd5-415e-9dcb-045278acb299@github.com>
Message-ID: <Fh5Z_IEV5s7lV-xc6-Ilmk0HU1Uf7FRX_pBXQRGp2i0=.1bf2fff2-9eef-48dc-ad17-f80f8d80f961@github.com>

On Mon, 9 Dec 2024 13:00:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Since this is my second merged PR to the OpenJDK, could I become one?

If you want to be, the process for becoming OpenJDK author is described here:
https://openjdk.org/projects/#project-author

The relevant project is `jdk`:
https://openjdk.org/census#jdk

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

PR Comment: https://git.openjdk.org/jdk/pull/22611#issuecomment-2527868999

From dnsimon at openjdk.org  Mon Dec  9 13:08:41 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 9 Dec 2024 13:08:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <oJRwVuQi7noeBJd-Rdac4oj_L6vLi70y7_Ciac8FkPM=.730ca59e-2dfe-4918-aec3-b1bcf287204b@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

JVMCI changes looks good.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2488753749

From coleenp at openjdk.org  Mon Dec  9 13:08:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:08:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <2XYWkmFgJ5-7Vhk5-GpOe-YNP_JbeLsRepbpnVV6S2s=.be92ebb7-faa6-4734-97fe-255d71f33aec@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

The JVM call is Class.getModifiers() and there are compiler intrinsics because I guess performance matters for this call.  Although maybe a future RFE could be to add this field to java.lang.Class and have the JVM set it instead and remove the intrinsic.

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

PR Comment: https://git.openjdk.org/jdk/pull/22618#issuecomment-2527876290

From coleenp at openjdk.org  Mon Dec  9 13:12:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:12:39 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
Message-ID: <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>

On Mon, 9 Dec 2024 13:00:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1119:
>> 
>>> 1117:   // to support Class.getModifiers().  Instance classes recalculate
>>> 1118:   // the cached flags after the class file is parsed, but before the
>>> 1119:   // class is put into the system dictionary.
>> 
>> Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.
>
> I thought the comment was referring to this code below that late calculates the modifier flags.  Don't know why system dictionary was called out though.

And they're not the same as access flags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875957344

From stuefe at openjdk.org  Mon Dec  9 13:21:46 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 9 Dec 2024 13:21:46 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v14]
In-Reply-To: <EdtR-1kRokz1nCbDySun_TIaamNXLE6HnqTwg_wNVb8=.69d7a297-a0d4-4bdd-b54b-667dfc0df732@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <EdtR-1kRokz1nCbDySun_TIaamNXLE6HnqTwg_wNVb8=.69d7a297-a0d4-4bdd-b54b-667dfc0df732@github.com>
Message-ID: <UTiXFva2qziLw-dQ17m6nsTKc60lfM3Wudcm3Fl9_Qk=.d3ad96a4-3ef3-4ea2-bfe6-cf5001fb9748@github.com>

On Fri, 6 Dec 2024 22:55:22 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add constant

Okay!

Needs a second review. @ashu-mehra, maybe?

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 49:

> 47: static const int MAX_REGIONS_RETURNED = 1000000;
> 48: 
> 49: /* 

Can you fix the whitespace error, please? jcheck should pass.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2488780245
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1875967453

From stooke at openjdk.org  Mon Dec  9 13:30:20 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 9 Dec 2024 13:30:20 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v15]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <gJJcleTu18yItlDawruLtsqxzYz4YGdIiDaVFpxfF8U=.3a93b4df-499f-4088-8a8f-1a8ed9b811e9@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

Simon Tooke has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace error
 - changes from revue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/7b7c9665..0bdef607

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=13-14

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

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

From stooke at openjdk.org  Mon Dec  9 13:30:20 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 9 Dec 2024 13:30:20 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v14]
In-Reply-To: <UTiXFva2qziLw-dQ17m6nsTKc60lfM3Wudcm3Fl9_Qk=.d3ad96a4-3ef3-4ea2-bfe6-cf5001fb9748@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <EdtR-1kRokz1nCbDySun_TIaamNXLE6HnqTwg_wNVb8=.69d7a297-a0d4-4bdd-b54b-667dfc0df732@github.com>
 <UTiXFva2qziLw-dQ17m6nsTKc60lfM3Wudcm3Fl9_Qk=.d3ad96a4-3ef3-4ea2-bfe6-cf5001fb9748@github.com>
Message-ID: <RjWdKEDk-x22hImxFhu1V_61vlnfn4oBqNFEANUzqho=.f82f3e41-9fef-4fda-9e17-6e336b00cb27@github.com>

On Mon, 9 Dec 2024 13:17:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add constant
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 49:
> 
>> 47: static const int MAX_REGIONS_RETURNED = 1000000;
>> 48: 
>> 49: /* 
> 
> Can you fix the whitespace error, please? jcheck should pass.

Done.  I have also converted all comments to '//' form for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1875978049

From dfuchs at openjdk.org  Mon Dec  9 13:30:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Dec 2024 13:30:43 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <vn5KixoVXSgvE9fcU5Pcd-y9NkYlVz86c8VG-g_P6OM=.3a4a66f2-9b24-49f8-9459-628ab9c8b229@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

changes to sun.net and java.naming/jdk.naming.* look ok

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2527957595

From coleenp at openjdk.org  Mon Dec  9 13:31:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:31:43 GMT
Subject: RFR: 8344922: Redefinition verifies the new klass when
 verification is disabled
In-Reply-To: <B_qrubLR9TMKbQb8Vi9qtMkegbvCCixHN1_K7nvWGOE=.08add72b-da11-43a0-98c4-c9f1b690a0c3@github.com>
References: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
 <B_qrubLR9TMKbQb8Vi9qtMkegbvCCixHN1_K7nvWGOE=.08add72b-da11-43a0-98c4-c9f1b690a0c3@github.com>
Message-ID: <cUNeEYMCYMJIcBlf5REvhJ2W9OtHEZdPUC2VgDWroD8=.f795c3ec-c6ed-4795-9997-147ec75d3665@github.com>

On Mon, 9 Dec 2024 02:08:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change only verifies redefined classes if Verification is enabled.  BytecodeVerificationRemote will be false for verification turned off.  If someone turns it off but BytecodeVerificationLocal on (which is non-sensical), the argument processing code will fix that up.  So all this needs to do is check for BytecodeVerifificationRemote for -Xverify:none (which is a deprecated option).
>> 
>> 
>>   // Treat the odd case where local verification is enabled but remote
>>   // verification is not as if both were enabled.
>>   if (BytecodeVerificationLocal && !BytecodeVerificationRemote) {
>>     log_info(verification)("Turning on remote verification because local verification is on");
>>     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>>   }
>> 
>> 
>> Tested with runtime/verifier, jck vm and tier1-4 (in progress), and the new test case.
>
> src/hotspot/share/classfile/verifier.cpp line 137:
> 
>> 135:   return (should_verify_class &&
>> 136:     // Override parameter (return false) if -Xverify:none
>> 137:     BytecodeVerificationRemote &&
> 
> Sorry but I don't understand why the correct value for `should_verify` doesn't filter through from `Verifier::should_verify_for`??? Seems to me that is the only place where we should explicitly check the verification flags.

I could check it in redefinition instead, here:

https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1461
and
https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1493

Or have another call should_verify_for_redefinition() which verifies things by default true even if from the bootclass.  Whichever you prefer.  The point is that we do want to verify bytecodes given during redefinition even for the bootclass path because they could be wrong and mess up everything.  Unless, one runs with -Xverify:none in which case you don't want to verify.  Although I said in the bug, this seems like a bad idea and there should be no reason to do this.  So, also maybe that can be the resolution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22617#discussion_r1875981587

From kevinw at openjdk.org  Mon Dec  9 14:02:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 14:02:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <CZvJVQu03QkOiUM5mcdagcdfDvo6SMRhg-OVi9-O9RY=.a676e608-9fbf-4224-a417-2b1e063275af@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Looks good.
They all seem to follow the pattern, I looked at some and yes they have changes in 2024 but no year update.  One of them was mine I noticed!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2488883450

From rriggs at openjdk.org  Mon Dec  9 15:19:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 15:19:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Copyright dates in third party files are not updated uniformly. See the previous comment.

That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489132284
PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528303669

From kevinw at openjdk.org  Mon Dec  9 15:28:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 15:28:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528357715

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
Message-ID: <QLNzClECNTKmLMG1OzFKoY6S9ZscAfwfF0BhnfJ6_PE=.6c75b36a-0b08-4c14-93b8-553deeb0dd48@github.com>

On Mon, 9 Dec 2024 15:26:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

That was certainly not intentional! I'm not sure how that happened, I need to look at my copyright update script again...

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528425161

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

  Revert changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/8e040c3a..c8d541f9

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

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

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

From ihse at openjdk.org  Mon Dec  9 15:48:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:48:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
Message-ID: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>

On Mon, 9 Dec 2024 15:16:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?

The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528451279

From kevinw at openjdk.org  Mon Dec  9 17:04:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 17:04:39 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <Bl7Ulu5GMnQe0ZKFzJGzLX_pnYqZ9TYWOPgDFau9_rE=.89cdd5bb-c5ce-4cb8-8191-a09bd5f01b60@github.com>

On Tue, 19 Nov 2024 00:04:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

Looks good I think.  (These are kind of hard to read, or hard to appreciate as a whole!)


VirtualMachineImpl.java and attachListener_PLATFORM.cpp have much in common between platforms, but maybe creating new common base classes is an interesting refactor work with not that much payoff.  Plus there are AIX versions that some of us don't build and test (which I think you mentioned elsewhere).



On Windows, attachListener_windows.cpp operations have:  assert(opened(), "must be");
...I was wondering if we don't need a similar assert in in src/hotspot/os/posix/attachListener_posix.cpp
But probably the different usage pattern explains that, i.e.
Windows' PipeChannel needs the open() method specifically called, but for Posix it creates the socket on construction.

(so this is fine, just some observations)

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

PR Review: https://git.openjdk.org/jdk/pull/22223#pullrequestreview-2489435258

From joehw at openjdk.org  Mon Dec  9 17:44:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 17:44:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <mu_rEJuYYxO7juUhV0qSjwkgt7XFhpnwddzS_bRgYcU=.fcc039a4-77c9-445a-9874-b934abeaefeb@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

The git query found all those java.xml properties files likely due to the jcheck change (JDK-8325558) you made. That patch correctly kept the copyright years as they were since we generally don't change copyright year unless the change is significant.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528864312

From mchung at openjdk.org  Mon Dec  9 18:01:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Dec 2024 18:01:37 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <SReh6u2czEgXid48w9XheeErSgeSc3O2_NKZFcl3nCc=.7c7f1e0e-cc65-4344-900d-e6e2fde25358@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22607#pullrequestreview-2489586744

From liach at openjdk.org  Mon Dec  9 18:37:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:42 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <-vHUTV6ABJZEaxVGeZ2FytzgMEIx-Cdcgm_I5TIuxo4=.5f76bd21-9378-4e52-949b-06ad59192bab@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22607#issuecomment-2529047739

From liach at openjdk.org  Mon Dec  9 18:37:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:43 GMT
Subject: [jdk24] Integrated: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <pKY85AZzy2hqc6ksUGd7oUO5wOaRP9FPj4dS5pha6k4=.f8a0d57a-a0c4-46cc-994e-844867b88e09@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a8132543
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a81325433d7da6b73abb37ea3e33489d0a3afbae
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung
Backport-of: 496641955041c5e48359e6256a4a61812653d900

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

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

From joehw at openjdk.org  Mon Dec  9 19:53:38 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 19:53:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <xsjhXJx2YAuLVr-ryIB6HgQo5pFQbbT5gwORtR-PwrI=.fc98b8c8-a0a7-4bd4-ab1e-1e42eed6b17f@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489899005

From sspitsyn at openjdk.org  Mon Dec  9 20:04:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 20:04:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <qHJoOG-oixqaOUOjQwxGRYPzhlrzp_7Q5QzaSvDkeqE=.7f469a1b-946e-4da9-8efa-0a8bf222ceab@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

I've looked at the Serviceability related copyright updates (prims, SA, debugger and tests). They are good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2489952883

From sspitsyn at openjdk.org  Mon Dec  9 20:28:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 20:28:38 GMT
Subject: RFR: 8305010: Test
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
 timed out: thread not suspended
In-Reply-To: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
References: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
Message-ID: <5euDYAmOwI4ATSsnmNBIFgj74bwpX0SSw89adCNMl1w=.e67b3f0d-bde7-49e2-ba47-b3915b563497@github.com>

On Wed, 4 Dec 2024 03:07:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and agent thread:
> The callbacks increments event counter and then do self-suspend;
> Agent thread waits when expected number of events is received, then performs verification and resumes the thread, but expected counter value does not mean the threads are suspended.

Good catch and fix.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22532#pullrequestreview-2490004963

From sspitsyn at openjdk.org  Mon Dec  9 20:54:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 20:54:41 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
Message-ID: <Ie6r22VKYYJUA7hnpQ9_DxaX4_5SymqVh2tRt_Bwa6w=.c3aa6067-a842-46ff-9d8f-f04511675a72@github.com>

On Fri, 6 Dec 2024 22:28:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
> 
> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
> 
> Testing:
> 
> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
> - [ ] tier1
> - [ ] tier2 svc
> - [ ] tier5 svc

The fix looks good modulo potential renaming of the `run1()` method.

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

PR Review: https://git.openjdk.org/jdk/pull/22620#pullrequestreview-2490055623

From ihse at openjdk.org  Mon Dec  9 21:09:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:09:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

  Revert mistaken changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0166c68e..5610a605

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

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

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

From rriggs at openjdk.org  Mon Dec  9 21:11:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 21:11:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
 <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
Message-ID: <mDL9FucpxYnDugHN7ibpYO5qP5o1qwhidL0fzZiTuog=.b93210c4-6fed-4f1b-9f4f-46b2673e41bd@github.com>

On Mon, 9 Dec 2024 15:45:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
>
>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
> 
> I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?
> 
> The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

@magicus My question was about third party (xml) code used from Apache.
Joe's review and approval resolved that question.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2529462025

From cjplummer at openjdk.org  Mon Dec  9 21:23:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Dec 2024 21:23:37 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <Ie6r22VKYYJUA7hnpQ9_DxaX4_5SymqVh2tRt_Bwa6w=.c3aa6067-a842-46ff-9d8f-f04511675a72@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <Ie6r22VKYYJUA7hnpQ9_DxaX4_5SymqVh2tRt_Bwa6w=.c3aa6067-a842-46ff-9d8f-f04511675a72@github.com>
Message-ID: <4Yk154ydoVHkw2AYwjovQLlSmY9dX2Sy9AZgxeaqrVk=.5b841d01-f240-4af4-807d-f3ad52773aa0@github.com>

On Mon, 9 Dec 2024 20:52:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks good modulo potential renaming of the `run1()` method.

I think you and @AlanBateman did quite understand what I meant by:

> It also needs to support test runs with platforms threads. See how run() checks if it is running in virtual thread mode or not. Either way it calls run(), but in the virtual thread case it does so using VThreadPinner.

The `run1()` method is called regardless of whether or not we are using vthreads and VThreadPinner, so I don't think `runPinned()` is a good name for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2529505051

From sspitsyn at openjdk.org  Mon Dec  9 21:48:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 21:48:36 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
Message-ID: <WelJh5Rv_3-egOOV1o9opqiCSBdRnr9kC5911W07XoE=.f99b7a96-ba7f-461b-a9ce-47a3d7899d8f@github.com>

On Fri, 6 Dec 2024 22:28:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
> 
> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
> 
> Testing:
> 
> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
> - [x] tier1
> - [x] tier2 svc
> - [x] tier5 svc

> I think you and @AlanBateman didn't quite understand what I meant by:
> . . .
> The run1() method is called regardless of whether or not we are using vthreads and VThreadPinner, so I don't think runPinned() is a good name for it.

In fact, I understand it. I was thinking if renaming to something like `runPlatformOrPinnedVirtual()` would work. But there is no pressure from me on this as the method name will become kind of lengthy. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2529588254

From cjplummer at openjdk.org  Mon Dec  9 22:06:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 9 Dec 2024 22:06:38 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <WelJh5Rv_3-egOOV1o9opqiCSBdRnr9kC5911W07XoE=.f99b7a96-ba7f-461b-a9ce-47a3d7899d8f@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <WelJh5Rv_3-egOOV1o9opqiCSBdRnr9kC5911W07XoE=.f99b7a96-ba7f-461b-a9ce-47a3d7899d8f@github.com>
Message-ID: <Fmnz7sFtwi8TLV6pgOo4LEFo5raQeRA_KiulVFjBsiA=.a4300532-b6be-4e96-9b9b-629172678c2f@github.com>

On Mon, 9 Dec 2024 21:44:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > I think you and @AlanBateman didn't quite understand what I meant by:
> > . . .
> > The run1() method is called regardless of whether or not we are using vthreads and VThreadPinner, so I don't think runPinned() is a good name for it.
> 
> In fact, I understand it. I was thinking if renaming to something like `runPlatformOrPinnedVirtual()` would work. But there is no pressure from me on this as the method name will become kind of lengthy. :)

It is wordy. Maybe runShared or runCommon, although I don't think either adds much value.

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2529621276

From amenkov at openjdk.org  Mon Dec  9 22:42:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 9 Dec 2024 22:42:38 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <Bl7Ulu5GMnQe0ZKFzJGzLX_pnYqZ9TYWOPgDFau9_rE=.89cdd5bb-c5ce-4cb8-8191-a09bd5f01b60@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <Bl7Ulu5GMnQe0ZKFzJGzLX_pnYqZ9TYWOPgDFau9_rE=.89cdd5bb-c5ce-4cb8-8191-a09bd5f01b60@github.com>
Message-ID: <MgdzKZrXDNAfproiLbuUV0enkkfa_QyeSSVr7TShRPo=.120daaef-c7c1-43b9-9de7-00396310b530@github.com>

On Mon, 9 Dec 2024 17:01:40 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> VirtualMachineImpl.java and attachListener_PLATFORM.cpp have much in common between platforms, but maybe creating new common base classes is an interesting refactor work with not that much payoff.

Yes, there a lot of common code between platforms and it can be refactored, but it would make the fix much bigger and harder to review.

> Plus there are AIX versions that some of us don't build and test (which I think you mentioned elsewhere).

Right. Most of the AIX code is copy of the posix/linux/macosx implementation, but I have no environment to build/test it, so I changed shared code to not break AIX build.

> On Windows, attachListener_windows.cpp operations have: assert(opened(), "must be"); ...I was wondering if we don't need a similar assert in in src/hotspot/os/posix/attachListener_posix.cpp But probably the different usage pattern explains that, i.e. Windows' PipeChannel needs the open() method specifically called, but for Posix it creates the socket on construction.

Right. The assert can be added to posix implementation, but it doesn't make much sense as SocketChannel does not opens the socket, but get it from the caller

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

PR Comment: https://git.openjdk.org/jdk/pull/22223#issuecomment-2529687621

From stooke at openjdk.org  Mon Dec  9 22:46:57 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 9 Dec 2024 22:46:57 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v16]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <nLIFDvEFMns8Jv_CTyqNmR-823GUWgUNuQO2wIZU7oc=.e9cda1bc-6b5a-4716-9915-7ffde35adc2c@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

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

  fix crash due to uninitilized pointer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/0bdef607..c2dc01cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=14-15

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

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

From jlu at openjdk.org  Mon Dec  9 23:01:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Dec 2024 23:01:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <GWjrBdyLJQ9FzJkSm8a68fiVZAVcVljFdJPmdRLTdrc=.3ef6fd4d-ead7-473f-8cf4-98f918711888@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Looked at the i18n changes (src, test, and 3rd party icu files w/ Oracle header) and they look correct to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2490302089

From dholmes at openjdk.org  Tue Dec 10 04:01:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 04:01:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <FQqaRMK8sCtC8DH4iJZXU2jWhNYIWiDtVgT0DTyN1jQ=.3df4d81c-39ef-4496-8ba5-ee17cb00e606@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

I scanned the full diff and also did some random checks. Looks good. Thanks for fixing.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2490894140

From tschatzl at openjdk.org  Tue Dec 10 07:20:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Dec 2024 07:20:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <46K2W9LUIv9jOu7TEtm4Js4TfgzBRyfwhntnqdaQTUY=.f4c7b046-942b-4fc9-9bb5-8690b1f33391@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

lgtm, looked at gc files in both shared and cpu and os specific directories.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2491237029

From ihse at openjdk.org  Tue Dec 10 08:51:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <cxbGNoeWXFNqKVFrQM26GTNE3i40jFwyXPW87pUXSjU=.cdcf3cec-99a6-45ad-aabc-9569a19ac46c@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Thanks for all reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2530834262

From ihse at openjdk.org  Tue Dec 10 08:51:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:46 GMT
Subject: Integrated: 8345795: Update copyright year to 2024 for hotspot in
 files where it was missed
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <L5e5EQstNUh6-uYcJ2g3fXB4YlyVbBVqorjQlw4f6ms=.7a58b6dd-6b71-432d-b2c5-d93fa998b3c9@github.com>

On Mon, 9 Dec 2024 12:11:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: 2979806c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2979806c72561cb4d4e8ac3d44dbcea347ace966
Stats:     921 lines in 921 files changed: 0 ins; 0 del; 921 mod

8345795: Update copyright year to 2024 for hotspot in files where it was missed

Reviewed-by: dholmes, tschatzl, dnsimon, sspitsyn

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

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

From dholmes at openjdk.org  Tue Dec 10 08:59:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 08:59:39 GMT
Subject: RFR: 8344922: Redefinition verifies the new klass when
 verification is disabled
In-Reply-To: <cUNeEYMCYMJIcBlf5REvhJ2W9OtHEZdPUC2VgDWroD8=.f795c3ec-c6ed-4795-9997-147ec75d3665@github.com>
References: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
 <B_qrubLR9TMKbQb8Vi9qtMkegbvCCixHN1_K7nvWGOE=.08add72b-da11-43a0-98c4-c9f1b690a0c3@github.com>
 <cUNeEYMCYMJIcBlf5REvhJ2W9OtHEZdPUC2VgDWroD8=.f795c3ec-c6ed-4795-9997-147ec75d3665@github.com>
Message-ID: <cZFQbHTDeZkhh_kPKKsjHPfQgJIZmXvISapVze9YbxI=.fff99dbc-dcda-47b1-a93e-3c2beaf7ad3d@github.com>

On Mon, 9 Dec 2024 13:27:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/verifier.cpp line 137:
>> 
>>> 135:   return (should_verify_class &&
>>> 136:     // Override parameter (return false) if -Xverify:none
>>> 137:     BytecodeVerificationRemote &&
>> 
>> Sorry but I don't understand why the correct value for `should_verify` doesn't filter through from `Verifier::should_verify_for`??? Seems to me that is the only place where we should explicitly check the verification flags.
>
> I could check it in redefinition instead, here:
> 
> https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1461
> and
> https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1493
> 
> Or have another call should_verify_for_redefinition() which verifies things by default true even if from the bootclass.  Whichever you prefer.  The point is that we do want to verify bytecodes given during redefinition even for the bootclass path because they could be wrong and mess up everything.  Unless, one runs with -Xverify:none in which case you don't want to verify.  Although I said in the bug, this seems like a bad idea and there should be no reason to do this.  So, also maybe that can be the resolution.

I guess I am confused as to what the rules are here. The normal rules are that verification is based on whether the file is loaded by trusted loader or not, and the values of ByteCodeVerificationLocal and BytecodeVerificationRemote. But then we wanted to say that for redefinition we always verify even if the loader is trusted. But now we want to say, except if all verification has been explicitly disabled.

I think I'd rather see a `should_verify_for_redefinition` capture that, if that is what the rules should be.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22617#discussion_r1877627989

From dholmes at openjdk.org  Tue Dec 10 09:05:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:05:44 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
Message-ID: <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>

On Mon, 9 Dec 2024 13:09:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I thought the comment was referring to this code below that late calculates the modifier flags.  Don't know why system dictionary was called out though.
>
> And they're not the same as access flags.

The "recalculate" is what is throwing me - that suggests the flags were already "calculated" somewhere. Does it really mean just "calculate" and that we do it between parsing and adding to SD? (Not that I know what the significance of that placement is meant to be.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877642184

From dholmes at openjdk.org  Tue Dec 10 09:11:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:11:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
Message-ID: <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>

On Mon, 9 Dec 2024 13:02:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/typeArrayKlass.hpp line 76:
>> 
>>> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
>>> 75: 
>>> 76:   // jvm support
>> 
>> "jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?
>
> ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.

Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877650366

From dholmes at openjdk.org  Tue Dec 10 09:11:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:11:43 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
Message-ID: <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>

On Tue, 10 Dec 2024 09:08:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.
>
> Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.

But still "jvm support" in the comment really doesn't explain anything.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877652152

From psadhukhan at openjdk.org  Tue Dec 10 09:33:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 10 Dec 2024 09:33:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

not sure why client label is added, no java.desktop/accessibility files are in there

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2530994967

From kevinw at openjdk.org  Tue Dec 10 09:54:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 10 Dec 2024 09:54:38 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <lfAFYQU_THd2l_ERVlvJETkN2n7OE4ME98Aany9MDNA=.d57edf9b-2dea-41f2-99e5-0156124f4637@github.com>

On Tue, 19 Nov 2024 00:04:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

Looks good, thanks, a couple of other notes here in case it helps anyone.


AttachOperation::write_reply(ReplyWriter * writer, jint result, const char* message, int message_len) 
is this only called by the write_reply method that passes message_len as strlen(stream) ?
The new check for len<0 might not really be useful but does no harm.

The existing "char msg[32]" is a buffer used to write the numeric jint result, not the message as the name might suggest.

HotSpotVirtualMachine.java already has writeCommand() that handles VERSION_2, so the Linux VirtualMachineImpl can just call it.  Also writeString is already there in HotSpotVirtualMachine, so removal from Linux is a good cleanup.


I'm sure we all want to find time for the future conversation about actually streaming the output rather than passing a single buffer around. 8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22223#pullrequestreview-2491720772

From stuefe at openjdk.org  Tue Dec 10 12:30:47 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 10 Dec 2024 12:30:47 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v16]
In-Reply-To: <nLIFDvEFMns8Jv_CTyqNmR-823GUWgUNuQO2wIZU7oc=.e9cda1bc-6b5a-4716-9915-7ffde35adc2c@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <nLIFDvEFMns8Jv_CTyqNmR-823GUWgUNuQO2wIZU7oc=.e9cda1bc-6b5a-4716-9915-7ffde35adc2c@github.com>
Message-ID: <wZjBPy8-L6Plb9a6ObNJ5JiiKkXVq8LZpeR9Y2Bo6bM=.9c4d45a1-c7bd-4152-ad72-ab940012aee5@github.com>

On Mon, 9 Dec 2024 22:46:57 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix crash due to uninitilized pointer

BTW make sure you merge and test again before integrating. Your branch is quite old. In fact, you should merge upstream often (The rule with merge vs rebase is: you merge after the patch has been un-drafted und RFR mail has been set out; before that, you can rebase).

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2531503100

From stooke at openjdk.org  Tue Dec 10 12:41:00 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 10 Dec 2024 12:41:00 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v17]
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Merge branch 'openjdk:master' into pr_macos_system_dump
 - fix crash due to uninitilized pointer
 - whitespace error
 - changes from revue
 - add constant
 - fix whitespace
 - combine like 128MB regions
 - fix trailing whitesdpae errors
 - latest cleanup, get rid of dll info
 - change format strings to display all digits properly
 - ... and 25 more: https://git.openjdk.org/jdk/compare/a6277bb5...c5cb0f97

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

Changes: https://git.openjdk.org/jdk/pull/20953/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=16
  Stats: 583 lines in 9 files changed: 505 ins; 40 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/20953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953

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

From coleenp at openjdk.org  Tue Dec 10 12:50:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 12:50:43 GMT
Subject: RFR: 8344922: Redefinition verifies the new klass when
 verification is disabled
In-Reply-To: <cZFQbHTDeZkhh_kPKKsjHPfQgJIZmXvISapVze9YbxI=.fff99dbc-dcda-47b1-a93e-3c2beaf7ad3d@github.com>
References: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
 <B_qrubLR9TMKbQb8Vi9qtMkegbvCCixHN1_K7nvWGOE=.08add72b-da11-43a0-98c4-c9f1b690a0c3@github.com>
 <cUNeEYMCYMJIcBlf5REvhJ2W9OtHEZdPUC2VgDWroD8=.f795c3ec-c6ed-4795-9997-147ec75d3665@github.com>
 <cZFQbHTDeZkhh_kPKKsjHPfQgJIZmXvISapVze9YbxI=.fff99dbc-dcda-47b1-a93e-3c2beaf7ad3d@github.com>
Message-ID: <YA-6BrJQDr0qzYOoENbFn5FxorIT4rx0fyzVxd64X4E=.906c12c9-6be1-4d32-8135-8638d2dcb37c@github.com>

On Tue, 10 Dec 2024 08:56:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I could check it in redefinition instead, here:
>> 
>> https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1461
>> and
>> https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiRedefineClasses.cpp#L1493
>> 
>> Or have another call should_verify_for_redefinition() which verifies things by default true even if from the bootclass.  Whichever you prefer.  The point is that we do want to verify bytecodes given during redefinition even for the bootclass path because they could be wrong and mess up everything.  Unless, one runs with -Xverify:none in which case you don't want to verify.  Although I said in the bug, this seems like a bad idea and there should be no reason to do this.  So, also maybe that can be the resolution.
>
> I guess I am confused as to what the rules are here. The normal rules are that verification is based on whether the file is loaded by trusted loader or not, and the values of ByteCodeVerificationLocal and BytecodeVerificationRemote. But then we wanted to say that for redefinition we always verify even if the loader is trusted. But now we want to say, except if all verification has been explicitly disabled.
> 
> I think I'd rather see a `should_verify_for_redefinition` capture that, if that is what the rules should be.

How are these rules specified?  I checked the JVMTI specification and it doesn't say anything about except:

<br class="Apple-interchange-newline">[JVMTI_ERROR_FAILS_VERIFICATION](https://docs.oracle.com/en/java/javase/23/docs/specs/jvmti.html#JVMTI_ERROR_FAILS_VERIFICATION)	The class bytes fail verification.

The reason we don't verify on the bootclass loader is because we control the bytecodes and it was considered a performance improvement not to do so.  For now I'm ignoring trusted loaders for now because in the code "trusted" includes the application class loader, and that is used for package access and not whether we run the verifier or not.  These rules are not in the specification, but in the documentation for the deprecated -Xverify option which I can't actually find in searches right now.

When classes on the bootclass loader are redefined, we really do want to verify the bytecodes.  There's no performance reason not to, and a lot of bad things that can happen to the system as a whole if the bytecodes are invalid.  So that's why RedefineClasses has always passed "true" to the verifier, but it's been ignored up to now even though the expectation in the redefine classes code was that these bytecodes would be verified.

Jiangli noticed that -Xverify:none does not affect this.  Whether it should or not I guess depends on why verification is turned off.  If for performance, or just running tests in different modes, this is a benign difference in behavior.

What we can do is close this as WNF, and add a release note to [JDK-8330606](https://bugs.openjdk.org/browse/JDK-8330606).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22617#discussion_r1878036921

From coleenp at openjdk.org  Tue Dec 10 12:59:44 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 12:59:44 GMT
Subject: Withdrawn: 8344922: Redefinition verifies the new klass when
 verification is disabled
In-Reply-To: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
References: <sJ5y1jrlz5chsGlJQnGNL_MnlsEU1pTBg0UoQa_kgyk=.2ff09283-7edf-4def-81c0-2c1bcfe9eaea@github.com>
Message-ID: <CcVFBrDCgpIdt6WaHes98liFV1KI3Njv_sBUaO5LjGU=.d0412c29-52c0-4466-bfb7-7e9f6f837173@github.com>

On Fri, 6 Dec 2024 21:34:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change only verifies redefined classes if Verification is enabled.  BytecodeVerificationRemote will be false for verification turned off.  If someone turns it off but BytecodeVerificationLocal on (which is non-sensical), the argument processing code will fix that up.  So all this needs to do is check for BytecodeVerifificationRemote for -Xverify:none (which is a deprecated option).
> 
> 
>   // Treat the odd case where local verification is enabled but remote
>   // verification is not as if both were enabled.
>   if (BytecodeVerificationLocal && !BytecodeVerificationRemote) {
>     log_info(verification)("Turning on remote verification because local verification is on");
>     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>   }
> 
> 
> Tested with runtime/verifier, jck vm and tier1-4 (in progress), and the new test case.

This pull request has been closed without being integrated.

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

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

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

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

  remove "jvm support"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/4d546b58..5d87b61a

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

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

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

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
 <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>
Message-ID: <MJ3NWA3ZmU-nJwMNhdsQM9NlaErywXeVbpXfD0mDMDA=.43a99efe-1b51-403d-a5a4-71ac2d6256f7@github.com>

On Tue, 10 Dec 2024 09:02:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> And they're not the same as access flags.
>
> The "recalculate" is what is throwing me - that suggests the flags were already "calculated" somewhere. Does it really mean just "calculate" and that we do it between parsing and adding to SD? (Not that I know what the significance of that placement is meant to be.)

So I did some old code reading.  We used to create the mirror when creating InstanceKlass, then later in ClassFileParser, we recalculated the modifier flags after the inner class attributes are added to the InstanceKlass.  Now we create the mirror after all of this.  Adding to the SystemDictionary is the point where the class is published so they have to be correct for that, which is what that part of the comment meant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878089439

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
 <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>
Message-ID: <Fu_oEZrD4HZmLswKMNrB_g1SRuZR7hSB577VtdPA-K8=.bbb4a14e-7314-4ed9-b917-2c29198935d4@github.com>

On Tue, 10 Dec 2024 09:08:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.
>
> But still "jvm support" in the comment really doesn't explain anything.

I think it means for Class.getModifiers but I can remove it.  But I don't think I'm going to push this anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878090566

From stooke at openjdk.org  Tue Dec 10 15:57:43 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 10 Dec 2024 15:57:43 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v16]
In-Reply-To: <wZjBPy8-L6Plb9a6ObNJ5JiiKkXVq8LZpeR9Y2Bo6bM=.9c4d45a1-c7bd-4152-ad72-ab940012aee5@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <nLIFDvEFMns8Jv_CTyqNmR-823GUWgUNuQO2wIZU7oc=.e9cda1bc-6b5a-4716-9915-7ffde35adc2c@github.com>
 <wZjBPy8-L6Plb9a6ObNJ5JiiKkXVq8LZpeR9Y2Bo6bM=.9c4d45a1-c7bd-4152-ad72-ab940012aee5@github.com>
Message-ID: <NlD7qDen2k9FVBJEfQPdTRjR2PcO8Fl5o4R_ZzfTGNc=.3d132915-10d7-4ac9-be6e-1d3690d3569c@github.com>

On Tue, 10 Dec 2024 12:28:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix crash due to uninitilized pointer
>
> BTW make sure you merge and test again before integrating. Your branch is quite old. In fact, you should merge upstream often (The rule with merge vs rebase is: you merge after the patch has been un-drafted und RFR mail has been set out; before that, you can rebase).

@tstuefe it looks like the aarch64 runner has been fixed.  After merging, all tests have passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2532132482

From amenkov at openjdk.org  Tue Dec 10 19:24:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 10 Dec 2024 19:24:44 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <lfAFYQU_THd2l_ERVlvJETkN2n7OE4ME98Aany9MDNA=.d57edf9b-2dea-41f2-99e5-0156124f4637@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <lfAFYQU_THd2l_ERVlvJETkN2n7OE4ME98Aany9MDNA=.d57edf9b-2dea-41f2-99e5-0156124f4637@github.com>
Message-ID: <u1IgXO9Rp5YLeMqXHh-5vKcFCDMiK8bd_-wtCfNily0=.ce1788a3-0e35-4dfa-9430-87530e8f2237@github.com>

On Tue, 10 Dec 2024 09:52:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Looks good, thanks, a couple of other notes here in case it helps anyone.
> 
> AttachOperation::write_reply(ReplyWriter * writer, jint result, const char* message, int message_len) is this only called by the write_reply method that passes message_len as strlen(stream) ? The new check for len<0 might not really be useful but does no harm.

There are couple calls from `AttachOperation::read_request` that passes `const char*` (`message_len` is -1 as the default value).
I.e we need 2 versions of write_reply - one for `bufferedStream` and another for `const char*`.

> The existing "char msg[32]" is a buffer used to write the numeric jint result, not the message as the name might suggest.

This is old code (similar to deleted from `PosixAttachOperation::complete`).
Do you want to rename `msg` to `buf`?

> I'm sure we all want to find time for the future conversation about actually streaming the output rather than passing a single buffer around. 8-)

I'm open for it :)

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

PR Comment: https://git.openjdk.org/jdk/pull/22223#issuecomment-2532670222

From dholmes at openjdk.org  Tue Dec 10 20:39:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 20:39:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
Message-ID: <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>

On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove "jvm support"

src/hotspot/share/oops/arrayKlass.hpp line 123:

> 121: 
> 122:   // jvm support
> 123:   jint compute_modifier_flags() const;

I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878813713

From kevinw at openjdk.org  Tue Dec 10 20:43:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 10 Dec 2024 20:43:37 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <u1IgXO9Rp5YLeMqXHh-5vKcFCDMiK8bd_-wtCfNily0=.ce1788a3-0e35-4dfa-9430-87530e8f2237@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <lfAFYQU_THd2l_ERVlvJETkN2n7OE4ME98Aany9MDNA=.d57edf9b-2dea-41f2-99e5-0156124f4637@github.com>
 <u1IgXO9Rp5YLeMqXHh-5vKcFCDMiK8bd_-wtCfNily0=.ce1788a3-0e35-4dfa-9430-87530e8f2237@github.com>
Message-ID: <UvvnoZnHkfPLamJ22cZKkmQfCFjc8zdT5UMONH_SR30=.2f6efbe0-bd06-42e6-b3c4-3ad9818ae8b1@github.com>

On Tue, 10 Dec 2024 19:21:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Do you want to rename msg to buf?
Don't worry about going back and renaming it just for me 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/22223#issuecomment-2532841540

From prr at openjdk.org  Tue Dec 10 21:11:39 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Dec 2024 21:11:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <y5MxVqW2c_JJCwWbHTaY6bsutW7nMDH_NjpmXzBCzr0=.c833f43b-6d46-4c90-9a2c-c14521114297@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> not sure why client label is added, no java.desktop/accessibility files are in there

I was puzzling over that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2532895836

From coleenp at openjdk.org  Tue Dec 10 21:55:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 21:55:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
Message-ID: <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>

On Tue, 10 Dec 2024 20:36:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove "jvm support"
>
> src/hotspot/share/oops/arrayKlass.hpp line 123:
> 
>> 121: 
>> 122:   // jvm support
>> 123:   jint compute_modifier_flags() const;
> 
> I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.

I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878922185

From amenkov at openjdk.org  Wed Dec 11 01:40:51 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Dec 2024 01:40:51 GMT
Subject: Integrated: 8305010: Test
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
 timed out: thread not suspended
In-Reply-To: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
References: <XUAdarLweoc3McEalRBjizRJb35qgcVCisWcn8PrH58=.794c9117-f3be-45c8-a49a-c8b9c256d8be@github.com>
Message-ID: <nMFyIzZaYxpNiEeKVHqU_RVNQSBJOUkZWYlogMeeAsQ=.ec01ab33-fe82-4bd0-aee9-35c6dbc0ec73@github.com>

On Wed, 4 Dec 2024 03:07:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The PR fixes race in the test between ThreadStart/ThreadEnd callbacks and agent thread:
> The callbacks increments event counter and then do self-suspend;
> Agent thread waits when expected number of events is received, then performs verification and resumes the thread, but expected counter value does not mean the threads are suspended.

This pull request has now been integrated.

Changeset: 2ddaa460
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ddaa460545e043008aaf0b7ce33191b7c588833
Stats:     38 lines in 1 file changed: 36 ins; 0 del; 2 mod

8305010: Test vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java timed out: thread not suspended

Reviewed-by: cjplummer, lmesnik, sspitsyn

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

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

From dholmes at openjdk.org  Wed Dec 11 02:52:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 02:52:48 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
Message-ID: <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>

On Tue, 10 Dec 2024 21:53:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayKlass.hpp line 123:
>> 
>>> 121: 
>>> 122:   // jvm support
>>> 123:   jint compute_modifier_flags() const;
>> 
>> I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.
>
> I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.

To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1879248142

From dholmes at openjdk.org  Wed Dec 11 04:57:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 04:57:41 GMT
Subject: RFR: 8345800: Update copyright year to 2024 for serviceability in
 files where it was missed
In-Reply-To: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
References: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
Message-ID: <-O63pJFv2OIGn8Olif3wn0o4uZvOjXJM21NSLs2L-AY=.5450b9d6-1b93-4985-b39b-11f0d6b3987a@github.com>

On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Looks fine. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22641#pullrequestreview-2494302930

From cjplummer at openjdk.org  Wed Dec 11 05:17:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Dec 2024 05:17:37 GMT
Subject: RFR: 8345800: Update copyright year to 2024 for serviceability in
 files where it was missed
In-Reply-To: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
References: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
Message-ID: <j6LNBRZirS4dnsX1liqzNwlY0HjyBcm0oWUqXrY7WGs=.1cb1b45b-02fb-4463-a5ae-ab08fc9b4793@github.com>

On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22641#pullrequestreview-2494338627

From jwaters at openjdk.org  Wed Dec 11 05:45:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 05:45: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: <IxLpCefAnv-iO7kAFhrT7ISgY--LyAlxsa6uw6b3hjk=.3494ae20-9aad-4ce8-8d2d-acafd37cc835@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 it open, I'm integrating this all at once when all the corresponding changesets are approved

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2533689602

From mli at openjdk.org  Wed Dec 11 09:40:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:40:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <tvt6RZcQwnigoiXNxV7oGeyYq0BSns6TkNEXDsBKiJw=.8e107751-d6c5-4630-8670-c832bc24b973@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Nice batch cleanup.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2494928848

From ihse at openjdk.org  Wed Dec 11 10:42:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 10:42:41 GMT
Subject: Integrated: 8345800: Update copyright year to 2024 for serviceability
 in files where it was missed
In-Reply-To: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
References: <lExmFfuklP6QLVH5CDs9DL8CM74aOAHw_aKZhdFfiNo=.39514bbd-2129-4eb1-b22f-5bbbb744eead@github.com>
Message-ID: <8l27FhFflmkDUv3akafFRxz3alMFavBidxojAo29yiY=.7a61e8af-206a-4418-b2ab-d09057329018@github.com>

On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: c9ec2716
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9ec2716a5486e6304caa863d00fe2f5ef975602
Stats:     35 lines in 35 files changed: 0 ins; 0 del; 35 mod

8345800: Update copyright year to 2024 for serviceability in files where it was missed

Reviewed-by: dholmes, cjplummer

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

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

From sspitsyn at openjdk.org  Wed Dec 11 11:24:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Dec 2024 11:24:42 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <u8p5mu11-QsoKRcioIaz6VeNDGSWbrEuxxzSx8kRz_0=.95700376-e788-46ba-b471-b744c2125af1@github.com>

On Tue, 19 Nov 2024 00:04:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

src/hotspot/os/posix/attachListener_posix.cpp line 145:

> 143:  private:
> 144:   // the connection to the client
> 145:   SocketChannel _socket;

Nit: The name `_socket` is misleading. I'd suggest to rename it to `_socket_channel`.

src/hotspot/share/services/attachListener.hpp line 251:

> 249:     // Attach client can make sanity connect/disconnect.
> 250:     // In the case we get "premature EOF" error.
> 251:     // If "may_be_empty" is true, the error is not logged.

Nits or two minor suggestions:
 - replace: "In the case" => "In that case"
 - replace: "may_be_empty" => may_be_empty

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1879883033
PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1879876017

From sspitsyn at openjdk.org  Wed Dec 11 11:28:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Dec 2024 11:28:37 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual.
In-Reply-To: <Fmnz7sFtwi8TLV6pgOo4LEFo5raQeRA_KiulVFjBsiA=.a4300532-b6be-4e96-9b9b-629172678c2f@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <WelJh5Rv_3-egOOV1o9opqiCSBdRnr9kC5911W07XoE=.f99b7a96-ba7f-461b-a9ce-47a3d7899d8f@github.com>
 <Fmnz7sFtwi8TLV6pgOo4LEFo5raQeRA_KiulVFjBsiA=.a4300532-b6be-4e96-9b9b-629172678c2f@github.com>
Message-ID: <pi9F_prL4H9TFzQNVzdfWN26uXWW2Id8RzIxcEnWHP4=.c075f70b-1244-40cb-b920-1523eddac476@github.com>

On Mon, 9 Dec 2024 22:03:43 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> It is wordy. Maybe runShared or runCommon, although I don't think either adds much value.

Or it can be just something like `doit()` or `test()`. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2535608530

From lancea at openjdk.org  Wed Dec 11 11:41:40 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Dec 2024 11:41:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <SnUMv7eXNRQU7c9T4Bi3BQkxaesNNYM1VxK3mY7ABJc=.102d4905-e86c-445e-8e31-e60a1a45249c@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2495330243

From kevinw at openjdk.org  Wed Dec 11 12:25:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 12:25:15 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from java.management
 Util class
Message-ID: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>

A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).

While here, there are a few imports of Util that are unnecessary.

No changes to the module visibility/exports.

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

Commit messages:
 - unused imports
 - 8345984: Remove redundant checkXXX methods from java.management Util class

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

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

From alanb at openjdk.org  Wed Dec 11 12:58:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Dec 2024 12:58:38 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class
In-Reply-To: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
Message-ID: <i47QI4mC__82sZ40jBs84Zi1Am8eHfPnQn_i1rcTOg0=.cab273af-7419-4f8a-a44b-ff9bbc245038@github.com>

On Wed, 11 Dec 2024 12:17:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
> 
> While here, there are a few imports of Util that are unnecessary.
> 
> No changes to the module visibility/exports.

This looks okay, you might have to bump the copyright on a few files.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22680#pullrequestreview-2495587969

From kevinw at openjdk.org  Wed Dec 11 12:58:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 12:58:39 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class
In-Reply-To: <i47QI4mC__82sZ40jBs84Zi1Am8eHfPnQn_i1rcTOg0=.cab273af-7419-4f8a-a44b-ff9bbc245038@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <i47QI4mC__82sZ40jBs84Zi1Am8eHfPnQn_i1rcTOg0=.cab273af-7419-4f8a-a44b-ff9bbc245038@github.com>
Message-ID: <wRJ5imA5D35s9LqM1OfbmpzNzDeuCh85O8kOKcVvpfY=.df61b560-6831-403b-9eca-ace9fc748960@github.com>

On Wed, 11 Dec 2024 12:53:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay, you might have to bump the copyright on a few files.

Thanks, yes I think the GcInfoBuilder.java file, will update.

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

PR Comment: https://git.openjdk.org/jdk/pull/22680#issuecomment-2535917919

From kevinw at openjdk.org  Wed Dec 11 13:04:51 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 13:04:51 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
Message-ID: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>

> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
> 
> While here, there are a few imports of Util that are unnecessary.
> 
> No changes to the module visibility/exports.

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/22680/files
  - new: https://git.openjdk.org/jdk/pull/22680/files/b27b6426..4b2872db

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

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

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

From alanb at openjdk.org  Wed Dec 11 13:11:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Dec 2024 13:11:41 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <ny1jo3qGZyW-H1jp8KHBYH82uwE6lbdVISLfrlsMQ18=.6f2bbf4d-ae47-4847-b3cb-aaf70c857fc6@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22680#pullrequestreview-2495624850

From schernyshev at openjdk.org  Wed Dec 11 13:24:56 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 11 Dec 2024 13:24:56 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v10]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <uMRVnn-5Cftgkx4b9w_oRC_fRORXvqQ_OJhGlgA4MSU=.38a55aa1-bc32-4cfd-85dc-dffbc4d6c481@github.com>

> 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 to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  moved warning to version agnostic ::adjust_controller

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/2a7e9d82..70617c9c

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

  Stats: 109 lines in 6 files changed: 83 ins; 22 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

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

From coleenp at openjdk.org  Wed Dec 11 14:12:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 14:12:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
 <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
Message-ID: <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>

On Wed, 11 Dec 2024 02:49:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.
>
> To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.

Klass has a pure virtual function for this, so ArrayKlass is abstract.  There isn't a reason to redeclare it in ArrayKlass.

     virtual jint compute_modifier_flags() const = 0;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1880266526

From kevinw at openjdk.org  Wed Dec 11 14:30:48 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 14:30:48 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one)
Message-ID: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>

Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().

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

Commit messages:
 - 8345987: java.management has two Util.newObjectName methods (remove one)

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

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

From asemenyuk at openjdk.org  Wed Dec 11 15:00:49 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 11 Dec 2024 15:00:49 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: <35Qz3OhiNBh_IyMyPfac5CJ6SYJ286ZNkAV7wjQlvqU=.5c742544-270f-4b00-8363-9e38164c4fea@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

Marked as reviewed by asemenyuk (Reviewer).

Updated my approval. Should not be a blocker for the integration if it was.

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

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2495927308
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2536227468

From schernyshev at openjdk.org  Wed Dec 11 15:22:26 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 11 Dec 2024 15:22:26 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
 <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>
Message-ID: <Gjqtsgk6O12U7FcE11QmMumtom6KfBsBsBdSG_mxZk0=.407eaf2e-1c72-4ead-b196-2ab94b254b3a@github.com>

On Fri, 6 Dec 2024 09:51:52 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - diverged after integration of JDK-8344177
>>    
>>    # Conflicts:
>>    #	src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java
>>  - update cgroup v1 in metrics
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - updated test (path is reduced)
>>  - updated test (path is reduced)
>>  - adjust path suffix in cgroup (v1) version specific code, when root != cgroup
>>  - Merge branch 'master' into JDK-8343191
>>  - warn wenn ../ encountered, update path adjustment
>>  - Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
>>    
>>    Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>
>>  - Merge branch 'master' into JDK-8343191
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/bd6d911c...2a7e9d82
>
> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322:
> 
>> 320:     } else {
>> 321:       log_warning(os, container)("Cgroup cpu/memory controller path includes '../', detected limits won't be accurate");
>> 322:     }
> 
> Please move this warning to `CgroupUtil::adjust_controller` and abort the adjustment, we don't need to issue this warning multiple times, and we'd not be able to adjust it to a path that will work. Showing the warning once should be sufficient. We shouldn't see this path in any non-moved scenarios. It would perhaps help if we included some detail why this warning is being shown. I suggest:
> 
> ```cgroup controller path seems to have moved (includes '.../'), detected limits won't be accurate```

Would you recommand also to include the paths in that warning? Something like
```cgroup controller path at '/sys/fs/cgroup' seems to have moved to '../../test', detected limits won't be accurate```
This way it will have all the necessary information to investigate customer cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1880397873

From sgehwolf at openjdk.org  Wed Dec 11 15:27:18 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 11 Dec 2024 15:27:18 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <Gjqtsgk6O12U7FcE11QmMumtom6KfBsBsBdSG_mxZk0=.407eaf2e-1c72-4ead-b196-2ab94b254b3a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
 <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>
 <Gjqtsgk6O12U7FcE11QmMumtom6KfBsBsBdSG_mxZk0=.407eaf2e-1c72-4ead-b196-2ab94b254b3a@github.com>
Message-ID: <6x7XcQ3isAojum3gJl0uNQ23xQvjZJMUhCaTAna7uSk=.2d2924fa-d92e-4167-bd81-b7afd11aab3d@github.com>

On Wed, 11 Dec 2024 15:19:06 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322:
>> 
>>> 320:     } else {
>>> 321:       log_warning(os, container)("Cgroup cpu/memory controller path includes '../', detected limits won't be accurate");
>>> 322:     }
>> 
>> Please move this warning to `CgroupUtil::adjust_controller` and abort the adjustment, we don't need to issue this warning multiple times, and we'd not be able to adjust it to a path that will work. Showing the warning once should be sufficient. We shouldn't see this path in any non-moved scenarios. It would perhaps help if we included some detail why this warning is being shown. I suggest:
>> 
>> ```cgroup controller path seems to have moved (includes '.../'), detected limits won't be accurate```
>
> Would you recommand also to include the paths in that warning? Something like
> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to '../../test', detected limits won't be accurate```
> This way it will have all the necessary information to investigate customer cases.

Seems fine yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1880407169

From mchung at openjdk.org  Wed Dec 11 17:21:17 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 11 Dec 2024 17:21:17 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <E-PGS25M63eR2g49rY9vJGHRvmytuSUKsQlqavYYRe8=.d15cdc2c-f631-4938-a797-21cb693e9268@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22680#pullrequestreview-2496338165

From kevinw at openjdk.org  Wed Dec 11 17:27:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 17:27:15 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <7AaT3ON_oYGJ-10XYXTfo-42362PgsKEBKqBJgsWjO0=.b1189219-481b-40f4-9cc3-638e78467ae7@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

Thanks Alan and Mandy!

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

PR Comment: https://git.openjdk.org/jdk/pull/22680#issuecomment-2536614757

From cjplummer at openjdk.org  Wed Dec 11 17:39:14 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Dec 2024 17:39:14 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
Message-ID: <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>

> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
> 
> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
> 
> Testing:
> 
> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
> - [x] tier1
> - [x] tier2 svc
> - [x] tier5 svc

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Rename run1() to test()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22620/files
  - new: https://git.openjdk.org/jdk/pull/22620/files/47ccd8db..d801499f

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

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

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

From cjplummer at openjdk.org  Wed Dec 11 18:51:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Dec 2024 18:51:13 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <b6pX0CAKjIHNPsdovohcoCAh0_5KtwBs_7YA_CG5rPs=.c45f3871-e384-411e-a3f4-6ea472814187@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22680#pullrequestreview-2496559877

From cjplummer at openjdk.org  Wed Dec 11 18:58:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Dec 2024 18:58:13 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one)
In-Reply-To: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
Message-ID: <y176CJHqT1BtcVT3j7Wy42c7crN5ZhLz5wn5pxa019k=.8e645c05-3e73-4a9a-8bb8-880d15a708d7@github.com>

On Wed, 11 Dec 2024 13:55:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().

src/java.management/share/classes/javax/management/ObjectName.java line 40:

> 38: import java.util.Map;
> 39: 
> 40: import static sun.management.Util.newObjectName;

What is the motivation for doing the static import? I prefer seeing Util.newObjectName().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1880745856

From sspitsyn at openjdk.org  Wed Dec 11 19:05:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Dec 2024 19:05:19 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
Message-ID: <8Q-ct_gAfThGjizd_H7lEtMdk-6XDot8BeMdDD2tQdw=.7bf51032-bbcd-4ddc-a70c-c01d4d9402ec@github.com>

On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
>> 
>> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
>> 
>> Testing:
>> 
>> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
>> - [x] tier1
>> - [x] tier2 svc
>> - [x] tier5 svc
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename run1() to test()

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22620#pullrequestreview-2496594500

From sspitsyn at openjdk.org  Wed Dec 11 19:28:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 11 Dec 2024 19:28:53 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <eSlltR60g1SGxxsfFOMA09u5xRZcP80yo5AbqUGooiQ=.82870381-f2b4-4bb0-8baf-bea9cd4f4bd9@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22680#pullrequestreview-2496643428

From ihse at openjdk.org  Wed Dec 11 21:10:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:52 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <m7oETe1RAtaoT1NyVmjhpbwEWCluWGDzOMgGKjgE-FU=.d15b5616-c416-47aa-89f5-c816d893f45e@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to binary files
>
> not sure why client label is added, no java.desktop/accessibility files are in there

@prsadhuk @prrace `src/java.base/share/classes/jdk/internal/access/JavaAWTFontAccess.java` matches the pattern `"src/java.base/share/classes/jdk/internal/access/\\w+AWT"` which is setup for `client` in the Skara `jdk.json` label configuration.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2537183864

From ihse at openjdk.org  Wed Dec 11 21:10:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:53 GMT
Subject: Integrated: 8345799: Update copyright year to 2024 for core-libs in
 files where it was missed
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <kZZWqqQs4ZIlaEEhWti7W4jqwB76v78dWz7Tk-kTzHE=.8da2847d-ec74-4fe4-b28e-e7c9a7b308b8@github.com>

On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: ddf04617
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddf04617887dc389cd7667e820da7ac91eea9e8c
Stats:     441 lines in 441 files changed: 0 ins; 0 del; 441 mod

8345799: Update copyright year to 2024 for core-libs in files where it was missed

Reviewed-by: joehw, jlu, mli, lancea, kevinw

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

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

From kevinw at openjdk.org  Wed Dec 11 21:17:50 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 11 Dec 2024 21:17:50 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one)
In-Reply-To: <y176CJHqT1BtcVT3j7Wy42c7crN5ZhLz5wn5pxa019k=.8e645c05-3e73-4a9a-8bb8-880d15a708d7@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <y176CJHqT1BtcVT3j7Wy42c7crN5ZhLz5wn5pxa019k=.8e645c05-3e73-4a9a-8bb8-880d15a708d7@github.com>
Message-ID: <nX4dvd7brwUxaxtbyR0KtkTBOfzHYcfJMaKF-CiJJLY=.99175e11-5595-4e54-8b2e-beeae961cb3b@github.com>

On Wed, 11 Dec 2024 18:55:11 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> src/java.management/share/classes/javax/management/ObjectName.java line 40:
> 
>> 38: import java.util.Map;
>> 39: 
>> 40: import static sun.management.Util.newObjectName;
> 
> What is the motivation for doing the static import? I prefer seeing Util.newObjectName().

Right, there are two Util classes, and some classes use both...
e.g. ObjectName.java uses com.sun.jmx.mbeanserver.Util (for Util.wildmatch()), 
and I want to use newObjectName from sun.management.Util.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1881014021

From amenkov at openjdk.org  Wed Dec 11 21:50:52 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Dec 2024 21:50:52 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v2]
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <aEMCy-V0pvOsezJagypc4Do6iGGRSsm96tgTVmuD-zE=.df88b33b-7f69-4d97-804d-3cc442d667ca@github.com>

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22223/files
  - new: https://git.openjdk.org/jdk/pull/22223/files/2ca15a18..ae364274

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

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

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

From amenkov at openjdk.org  Wed Dec 11 21:56:20 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Dec 2024 21:56:20 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v3]
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <TKdlXH8_UzaoVg2x-rR40kzg2mG-Tu-lK4grf2hiVE0=.448d77f7-14a4-4d11-8e57-bbe80f61135c@github.com>

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  updated comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22223/files
  - new: https://git.openjdk.org/jdk/pull/22223/files/ae364274..27bb3c43

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

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

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

From amenkov at openjdk.org  Wed Dec 11 21:56:20 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Dec 2024 21:56:20 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v3]
In-Reply-To: <UvvnoZnHkfPLamJ22cZKkmQfCFjc8zdT5UMONH_SR30=.2f6efbe0-bd06-42e6-b3c4-3ad9818ae8b1@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <lfAFYQU_THd2l_ERVlvJETkN2n7OE4ME98Aany9MDNA=.d57edf9b-2dea-41f2-99e5-0156124f4637@github.com>
 <u1IgXO9Rp5YLeMqXHh-5vKcFCDMiK8bd_-wtCfNily0=.ce1788a3-0e35-4dfa-9430-87530e8f2237@github.com>
 <UvvnoZnHkfPLamJ22cZKkmQfCFjc8zdT5UMONH_SR30=.2f6efbe0-bd06-42e6-b3c4-3ad9818ae8b1@github.com>
Message-ID: <LAMMb1Mz6_YiSFwNKmFiyqbSkrZri8PTUvC6472PthU=.c4dcfc5f-075b-46cf-b9cd-e4e421948cc0@github.com>

On Tue, 10 Dec 2024 20:41:04 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > Do you want to rename msg to buf?
> Don't worry about going back and renaming it just for me 8-)

Did it with the last update

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

PR Comment: https://git.openjdk.org/jdk/pull/22223#issuecomment-2537271364

From amenkov at openjdk.org  Wed Dec 11 21:56:21 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Dec 2024 21:56:21 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v3]
In-Reply-To: <u8p5mu11-QsoKRcioIaz6VeNDGSWbrEuxxzSx8kRz_0=.95700376-e788-46ba-b471-b744c2125af1@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <u8p5mu11-QsoKRcioIaz6VeNDGSWbrEuxxzSx8kRz_0=.95700376-e788-46ba-b471-b744c2125af1@github.com>
Message-ID: <EgqmG92n9mEazzODDo0WeS64_r_WQ6VMMc8dKy_cKjQ=.e68b2a19-5f7d-47fc-94cc-4fc519985fe9@github.com>

On Wed, 11 Dec 2024 11:17:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/hotspot/os/posix/attachListener_posix.cpp line 145:
> 
>> 143:  private:
>> 144:   // the connection to the client
>> 145:   SocketChannel _socket;
> 
> Nit: The name `_socket` is misleading. I'd suggest to rename it to `_socket_channel`.

Fixed

> src/hotspot/share/services/attachListener.hpp line 251:
> 
>> 249:     // Attach client can make sanity connect/disconnect.
>> 250:     // In the case we get "premature EOF" error.
>> 251:     // If "may_be_empty" is true, the error is not logged.
> 
> Nits or two minor suggestions:
>  - replace: "In the case" => "In that case"
>  - replace: "may_be_empty" => may_be_empty

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1881052345
PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1881052094

From cjplummer at openjdk.org  Wed Dec 11 22:48:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 11 Dec 2024 22:48:35 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one)
In-Reply-To: <nX4dvd7brwUxaxtbyR0KtkTBOfzHYcfJMaKF-CiJJLY=.99175e11-5595-4e54-8b2e-beeae961cb3b@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <y176CJHqT1BtcVT3j7Wy42c7crN5ZhLz5wn5pxa019k=.8e645c05-3e73-4a9a-8bb8-880d15a708d7@github.com>
 <nX4dvd7brwUxaxtbyR0KtkTBOfzHYcfJMaKF-CiJJLY=.99175e11-5595-4e54-8b2e-beeae961cb3b@github.com>
Message-ID: <bZkIERoE7ZjWX33DSD92NVL-PMS3cmSWWMdMFJ8vrMY=.a90e416c-d97b-45d4-8475-68f02e426574@github.com>

On Wed, 11 Dec 2024 21:15:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Right, there are two Util classes, and some classes use both... e.g. ObjectName.java uses com.sun.jmx.mbeanserver.Util (for Util.wildmatch()), and I want to use newObjectName from sun.management.Util.

In that case I'd probably just use the fully qualified class name when making the call and not even bother with an import. Static imports make the code harder to read because it looks like you are calling a method of the class that the call is being made from.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1881115322

From wkemper at openjdk.org  Thu Dec 12 00:05:45 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 00:05:45 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode is
 enabled
Message-ID: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>

This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

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

Commit messages:
 - Fix summary, remove debugging
 - Separate test for Shenandoah's generational mode

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

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

From schernyshev at openjdk.org  Thu Dec 12 01:11:33 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 12 Dec 2024 01:11:33 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v11]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <D4V5xdxqaBpLXU69Yb9Y5NucgGua5zs9afZehvltm14=.12185e97-4000-4998-ace2-58e110a61623@github.com>

> 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 to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  added details in the log message

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/70617c9c..a3002a92

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

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

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

From schernyshev at openjdk.org  Thu Dec 12 01:15:42 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 12 Dec 2024 01:15:42 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <6x7XcQ3isAojum3gJl0uNQ23xQvjZJMUhCaTAna7uSk=.2d2924fa-d92e-4167-bd81-b7afd11aab3d@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
 <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>
 <Gjqtsgk6O12U7FcE11QmMumtom6KfBsBsBdSG_mxZk0=.407eaf2e-1c72-4ead-b196-2ab94b254b3a@github.com>
 <6x7XcQ3isAojum3gJl0uNQ23xQvjZJMUhCaTAna7uSk=.2d2924fa-d92e-4167-bd81-b7afd11aab3d@github.com>
Message-ID: <Ci5FvFLu0ZFVYL3ejhj9W3cxVtd14DKVV7IYeUFnZpg=.f8bc1a49-dfe2-4bcb-b89b-1db9035b8ba5@github.com>

On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to '../../test', detected limits won't be accurate```
>> This way it will have all the necessary information to investigate customer cases.
>
> Seems fine yes.

Updated the log message. The log example in cg v1:

[0.001s][trace][os,container] OSContainer::init: Initializing Container Support
[0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.001s][warning][os,container] Cgroup memory controller path at '/sys/fs/cgroup/memory' seems to have moved to '/../../test', detected limits won't be accurate
[0.001s][debug  ][os,container] OSContainer::init: is_containerized() = true because all controllers are mounted read-only (container case)
[0.001s][trace  ][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
[0.001s][trace  ][os,container] CPU Quota is: -1
[0.002s][trace  ][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
[0.002s][trace  ][os,container] CPU Period is: 100000
[0.002s][trace  ][os,container] OSContainer::active_processor_count: 48
[0.002s][trace  ][os,container] CgroupSubsystem::active_processor_count (cached): 48
[0.002s][trace  ][os,container] total physical memory: 133623721984
[0.002s][trace  ][os,container] Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
[0.002s][trace  ][os,container] Memory Limit is: 419430400
[0.004s][trace  ][os,container] CgroupSubsystem::active_processor_count (cached): 48
[0.027s][trace  ][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
[0.027s][trace  ][os,container] CPU Quota is: -1
[0.027s][trace  ][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
[0.027s][trace  ][os,container] CPU Period is: 100000
[0.027s][trace  ][os,container] OSContainer::active_processor_count: 48
openjdk version "24-internal" 2025-03-18
OpenJDK Runtime Environment (build 24-internal-adhoc.bellsoft.jdk)
OpenJDK 64-Bit Server VM (build 24-internal-adhoc.bellsoft.jdk, mixed mode, sharing)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1881224417

From dholmes at openjdk.org  Thu Dec 12 07:48:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 07:48:40 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
Message-ID: <5hg27Hnzf2dbEZbYxyJoVFxBSvrrO9a36DjjWN4A5Zw=.d7b55ac2-db43-4d22-b14f-fcd5b4720a7b@github.com>

On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove "jvm support"

LGTM. Sorry for the  "red herrings".

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2498127779

From dholmes at openjdk.org  Thu Dec 12 07:48:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 07:48:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
 <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
 <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>
Message-ID: <03PAzWTc7UJmXroMZvBvW-xEZITKyaAOnfQLkswxMOo=.2ddea14d-825d-413c-8759-47d879cd98fe@github.com>

On Wed, 11 Dec 2024 14:10:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.
>
> Klass has a pure virtual function for this, so ArrayKlass is abstract.  There isn't a reason to redeclare it in ArrayKlass.
> 
>      virtual jint compute_modifier_flags() const = 0;

Sorry I didn't realize that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1881532974

From kevinw at openjdk.org  Thu Dec 12 09:18:45 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 09:18:45 GMT
Subject: Integrated: 8345984: Remove redundant checkXXX methods from
 java.management Util class
In-Reply-To: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
Message-ID: <b3DIm3Jso3YKeR63JE1beJEC0BsahFO4Y1GvIbp9zVA=.1c043e4b-7f31-4908-b0e9-aab9710236c2@github.com>

On Wed, 11 Dec 2024 12:17:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
> 
> While here, there are a few imports of Util that are unnecessary.
> 
> No changes to the module visibility/exports.

This pull request has now been integrated.

Changeset: 3f2556b8
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f2556b86079fbdba848b1ac16b62a376386999b
Stats:     16 lines in 4 files changed: 0 ins; 15 del; 1 mod

8345984: Remove redundant checkXXX methods from java.management Util class

Reviewed-by: alanb, mchung, cjplummer, sspitsyn

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

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

From kevinw at openjdk.org  Thu Dec 12 09:18:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 09:18:44 GMT
Subject: RFR: 8345984: Remove redundant checkXXX methods from
 java.management Util class [v2]
In-Reply-To: <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
References: <AXrlP1kUjG1Wh4RDNa78_l757f-flcbIWwmatxnRViY=.0308313b-6fb4-4bf4-aebb-51a5dec60f79@github.com>
 <8lCtMh0ZXWX_SyumKbdZ9g4rFk6ioGY8KCZkX4iurHs=.52cdf672-781d-43c8-9201-db120ee47a75@github.com>
Message-ID: <LYE30K4fUmTkno0dwt_5Ix4x_9NADIipcNHBoeFHD2s=.0dcf6f0c-f1a8-4e1d-8e58-272dab4d07e2@github.com>

On Wed, 11 Dec 2024 13:04:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> A post-SecurityManager removal cleanup task, to remove checkAccess(), checkMonitorAccess() and checkControlAccess() from src/java.management/share/classes/sun/management/Util.java (methods are already no-ops).
>> 
>> While here, there are a few imports of Util that are unnecessary.
>> 
>> No changes to the module visibility/exports.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   (C)

Thanks Chris and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/22680#issuecomment-2538298227

From kevinw at openjdk.org  Thu Dec 12 09:54:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 09:54:03 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
Message-ID: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>

> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().

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 three additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
 - static imports
 - 8345987: java.management has two Util.newObjectName methods (remove one)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22681/files
  - new: https://git.openjdk.org/jdk/pull/22681/files/e11cfd03..965b4264

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

  Stats: 8425 lines in 1104 files changed: 4478 ins; 1359 del; 2588 mod
  Patch: https://git.openjdk.org/jdk/pull/22681.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22681/head:pull/22681

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

From kevinw at openjdk.org  Thu Dec 12 09:57:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 09:57:36 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <bZkIERoE7ZjWX33DSD92NVL-PMS3cmSWWMdMFJ8vrMY=.a90e416c-d97b-45d4-8475-68f02e426574@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <y176CJHqT1BtcVT3j7Wy42c7crN5ZhLz5wn5pxa019k=.8e645c05-3e73-4a9a-8bb8-880d15a708d7@github.com>
 <nX4dvd7brwUxaxtbyR0KtkTBOfzHYcfJMaKF-CiJJLY=.99175e11-5595-4e54-8b2e-beeae961cb3b@github.com>
 <bZkIERoE7ZjWX33DSD92NVL-PMS3cmSWWMdMFJ8vrMY=.a90e416c-d97b-45d4-8475-68f02e426574@github.com>
Message-ID: <XOs7h0lC_yMwaCZ9q8Salw4q9ByqA3MQrEoo69EF9S4=.fda390e2-1cfd-4a93-9a46-064816bafbbd@github.com>

On Wed, 11 Dec 2024 22:46:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Right, there are two Util classes, and some classes use both...
>> e.g. ObjectName.java uses com.sun.jmx.mbeanserver.Util (for Util.wildmatch()), 
>> and I want to use newObjectName from sun.management.Util.
>
>> Right, there are two Util classes, and some classes use both... e.g. ObjectName.java uses com.sun.jmx.mbeanserver.Util (for Util.wildmatch()), and I want to use newObjectName from sun.management.Util.
> 
> In that case I'd probably just use the fully qualified class name when making the call and not even bother with an import. Static imports make the code harder to read because it looks like you are calling a method of the class that the call is being made from.

Sure, updated to use the method with its qualified class name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1881746491

From stuefe at openjdk.org  Thu Dec 12 11:44:46 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 11:44:46 GMT
Subject: RFR: 8339313: 32-bit build broken
Message-ID: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>

Two fixes to fix the 32-bit build.

See JBS issue and code comment for details.

I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

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

Commit messages:
 - fix

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

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

From coleenp at openjdk.org  Thu Dec 12 12:57:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 12:57:38 GMT
Subject: RFR: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <0jxhDfXcR06eY1f1Qi1hQe3tDpv8dXYcDHHHfODiiq8=.f2cb48c1-407a-4fbe-a160-c79a56f15f9c@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

Seems reasonable.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22707#pullrequestreview-2499421510

From stuefe at openjdk.org  Thu Dec 12 12:57:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 12:57:39 GMT
Subject: RFR: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <suLm0RllbvLZbXrNwpC0EGGTy-qviv-91TE3qmKwBH8=.dd56166e-d8e4-409c-ae89-41c94809b41c@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

@MBaesken?

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

PR Comment: https://git.openjdk.org/jdk/pull/22707#issuecomment-2538824157

From mbaesken at openjdk.org  Thu Dec 12 14:18:36 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Dec 2024 14:18:36 GMT
Subject: RFR: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <bCk8J-3Zo2glZOllEeviUtKO09hK-D6f_65HoN614vU=.3bdf4259-7a40-408a-9391-0ba5b4148b86@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22707#pullrequestreview-2499782928

From szaldana at openjdk.org  Thu Dec 12 14:27:36 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 12 Dec 2024 14:27:36 GMT
Subject: RFR: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <UsrTR4N3k8FwS1XanVnBQyKufF6Jd5qRGtzxKBgO91g=.942e46d5-9f5f-4794-992a-34bde5b9b528@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

I am not a Reviewer but this makes sense to me.

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

Marked as reviewed by szaldana (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22707#pullrequestreview-2499806819

From coleenp at openjdk.org  Thu Dec 12 14:51:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 14:51:02 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v3]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

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

 - Merge branch 'master' into modifiers
 - remove "jvm support"
 - 8345678: compute_modifiers should not be in create_mirror

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/5d87b61a..a0792dff

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

  Stats: 14988 lines in 2730 files changed: 7860 ins; 2341 del; 4787 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

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

From cjplummer at openjdk.org  Thu Dec 12 18:27:39 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 12 Dec 2024 18:27:39 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <-6SR-qmgUxhPpo3mQ773b0Ql3xrMVf4qkEMpcv5gbDc=.5cbc065c-361c-4035-9746-4234839033ee@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22681#pullrequestreview-2500474152

From kevinw at openjdk.org  Thu Dec 12 18:27:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 18:27:40 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <mf1UCP6htlhTWuZeWx85QherSZZXdyyU2JPsm9EAYrk=.e38f16c0-5020-4bd3-8c4e-c0a5000e8c7e@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Thanks Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/22681#issuecomment-2539725526

From amenkov at openjdk.org  Thu Dec 12 18:45:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 12 Dec 2024 18:45:42 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <xEacEFKrPD8vfucSM-G-6tP8KRDV7iBR0KXUHpMxKrs=.385872ea-7efa-4bd3-a986-d97807c6a475@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22681#pullrequestreview-2500509841

From stuefe at openjdk.org  Thu Dec 12 18:56:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 18:56:41 GMT
Subject: RFR: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <FOzTUzQUDkI-iG-dROyiKTq4BmrZacX9LvgcQkmhliA=.ee01ba96-2682-47e3-90c7-7f2d1a3e5d13@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

Thank you all.

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

PR Comment: https://git.openjdk.org/jdk/pull/22707#issuecomment-2539776889

From stuefe at openjdk.org  Thu Dec 12 18:56:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 18:56:41 GMT
Subject: Integrated: 8339313: 32-bit build broken
In-Reply-To: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
References: <-Dhrfw1_6fmPs8awvI2JW2x3jvRmcDY4CXfc6-iBtzA=.42d04f7d-70a6-498f-8af5-cd03b17ad06c@github.com>
Message-ID: <kBEMEL4-dMTKFKwH41A9Zlk4d9pdxUIn5KtW2h4TQrY=.80f6a077-7c4c-479b-95ad-13b326f62a24@github.com>

On Thu, 12 Dec 2024 11:39:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Two fixes to fix the 32-bit build.
> 
> See JBS issue and code comment for details.
> 
> I ran nNoClassDefFoundErrorTest x64 and x86 fastdebug and release. On fastdebug, the giant string test now gets silently skipped as expected.

This pull request has now been integrated.

Changeset: e9ad27fc
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9ad27fcdcb59be573ffd20811e82bced7c78948
Stats:     11 lines in 2 files changed: 10 ins; 0 del; 1 mod

8339313: 32-bit build broken

Reviewed-by: coleenp, mbaesken, szaldana

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

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

From szaldana at openjdk.org  Thu Dec 12 19:56:50 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 12 Dec 2024 19:56:50 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v17]
In-Reply-To: <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
Message-ID: <gNUR0pCkH8feTjksG3er-8KJ7-LbPtUhiFo8ThM3CjY=.fea27b19-dc3a-4424-b114-67a63b4aa11b@github.com>

On Tue, 10 Dec 2024 12:41:00 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'openjdk:master' into pr_macos_system_dump
>  - fix crash due to uninitilized pointer
>  - whitespace error
>  - changes from revue
>  - add constant
>  - fix whitespace
>  - combine like 128MB regions
>  - fix trailing whitesdpae errors
>  - latest cleanup, get rid of dll info
>  - change format strings to display all digits properly
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/a6277bb5...c5cb0f97

I am not a Reviewer but this looks good to me. I left a small comment inline. Thanks Simon!

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 352:

> 350:       break;
> 351:     }
> 352:     ::bzero(&region_info_with_path, sizeof(region_info_with_path));

Should we use memset instead?

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

Marked as reviewed by szaldana (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2500635094
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1882788888

From dholmes at openjdk.org  Thu Dec 12 20:44:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 20:44:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <WhHwLyr5V_dFU4Vw2270rfXYLolud7ZzdDVnxzHEMpU=.4eb9c6b4-52a5-4e82-abd8-2fe3ad02bb54@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

Seems okay. Someone from serviceability should give their opinion on the content.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2500741205

From duke at openjdk.org  Thu Dec 12 21:45:36 2024
From: duke at openjdk.org (Larry Cable)
Date: Thu, 12 Dec 2024 21:45:36 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

I do not understand the use case that this additional information solves for, nor does the bug provide any further enlightenment, I think this ER requires more rationale to motivate its inclusion.

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2540071738

From kevinw at openjdk.org  Thu Dec 12 23:15:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 12 Dec 2024 23:15:40 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <qGM7l-pHOqJhe__dwtw39LU4LrIa1XPUCSh0zwhSddY=.af8cdde7-ba5d-415c-9609-2718c7d978e5@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Thanks Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/22681#issuecomment-2540193640

From amenkov at openjdk.org  Thu Dec 12 23:36:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 12 Dec 2024 23:36:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <TLPWKQb93hgLMUpup_8UIOI57t9FWsLdwHhKMUQBLvQ=.fda44abd-a727-4943-9264-161e3a1ba693@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

src/hotspot/share/runtime/os.cpp line 1128:

> 1126: #if INCLUDE_JVMTI
> 1127:   // should return all kinds of JVMTI agents, but no xrun agents
> 1128:   const JvmtiAgentList::Iterator it =JvmtiAgentList::agents();

Suggestion:

  const JvmtiAgentList::Iterator it = JvmtiAgentList::agents();

src/hotspot/share/runtime/os.cpp line 1141:

> 1139:       const char* optionsinfo = agent->options();
> 1140:       const char* pathinfo = agent->os_lib_path();
> 1141:       if (agent->is_dynamic()) dyninfo = "dynamic";

maybe just initialize it as

      const char* dyninfo = agent->is_dynamic() ? "dynamic" : "";

(and the same for instrumentinfo/loadinfo/initinfo)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1883027329
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1883030064

From ysr at openjdk.org  Fri Dec 13 00:32:40 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Dec 2024 00:32:40 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode
 is enabled
In-Reply-To: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
Message-ID: <WB-FFl9BoXeevGboUGrVcpRPpbBAaIpSZmGwqLbEbKw=.b2fbd9d2-cd84-478a-b67c-83f612129d5d@github.com>

On Thu, 12 Dec 2024 00:01:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22695#pullrequestreview-2501025857

From ysr at openjdk.org  Fri Dec 13 00:36:35 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Dec 2024 00:36:35 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode
 is enabled
In-Reply-To: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
Message-ID: <WmiOOX2vTvg2tO3hmrMvqmfuLTEaU8tRieL3_iaIxtI=.b5335d0a-e5d5-4b6f-9e74-fe3c57feacd3@github.com>

On Thu, 12 Dec 2024 00:01:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java line 62:

> 60: /*
> 61:  * @test id=Genshen
> 62:  * @bug     4530538

Idle thought: should this stay 4530538 (I suppose!), or should it be 8346051? :-) 
Probably should stay 4530538 because of https://openjdk.org/jtreg/faq.html#how-do-i-run-only-tests-which-were-written-for-a-specific-bugid .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22695#discussion_r1883074087

From lmesnik at openjdk.org  Fri Dec 13 01:00:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 01:00:36 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode
 is enabled
In-Reply-To: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
Message-ID: <copsdBu7EnqFG6wdu5WBRXKoctgeLuhIMBe1njd3F04=.d50267e2-60b2-4069-92a5-7453ff712fc7@github.com>

On Thu, 12 Dec 2024 00:01:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

Please update copyrights.

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

PR Review: https://git.openjdk.org/jdk/pull/22695#pullrequestreview-2501048328

From lmesnik at openjdk.org  Fri Dec 13 01:28:32 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 01:28:32 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <9Y0orIXLTFkFaZEuqsJpnkLf1t18UA0WwSbB_Fgtii8=.1b908e7c-8d24-47ff-a2ae-2634c97e08d5@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Changes requested by lmesnik (Reviewer).

src/java.management/share/classes/javax/management/ObjectName.java line 1225:

> 1223:         if (name.getClass().equals(ObjectName.class))
> 1224:             return name;
> 1225:         return sun.management.Util.newObjectName(name.getSerializedNameString());

The newObjectName methods are different in 2 Utils.
The share/classes/sun/management/Util.java is

  45   ?     public static ObjectName newObjectName(String name) {
  46   ?         try {
  47   ?             return ObjectName.getInstance(name);
  48   ?         } catch (MalformedObjectNameException e) {
  49   ?             throw new IllegalArgumentException(e);
  50   ?         }
  51   ?     }

Isn't it infinite recursion?

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

PR Review: https://git.openjdk.org/jdk/pull/22681#pullrequestreview-2501062283
PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1883103577

From vaivanov at openjdk.org  Fri Dec 13 02:17:33 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 13 Dec 2024 02:17:33 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
Message-ID: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>

> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.

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

 - Merge branch 'openjdk:master' into 8341481
 - 8341481: [perf] vframeStreamCommon constructor may be optimized
 - 8341481 [Perf] vframeStreamCommon constructor may be optimized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22173/files
  - new: https://git.openjdk.org/jdk/pull/22173/files/55466835..ba234c59

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

  Stats: 530558 lines in 8910 files changed: 288054 ins; 192740 del; 49764 mod
  Patch: https://git.openjdk.org/jdk/pull/22173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22173/head:pull/22173

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

From amenkov at openjdk.org  Fri Dec 13 02:27:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 02:27:12 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest
Message-ID: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>

In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
The fix adds handling of the errors to get information for analysis.

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

Commit messages:
 - test update

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

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

From mbaesken at openjdk.org  Fri Dec 13 08:37:36 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 08:37:36 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v3]
In-Reply-To: <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
 <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>
Message-ID: <N4TJrgjUK4Ry0RNCdLq7Epjyu3Am43VJ3IaU2NTLtCA=.c2d2ef67-12d3-44b8-a213-2ad756f9c8b2@github.com>

On Thu, 12 Dec 2024 21:43:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> I do not understand the use case that this additional information solves for, nor does the bug provide any further enlightenment, I think this ER requires more rationale to motivate its inclusion.

Currently the info about the JVMTI agents in the hserr/hsinfo is not good. You might see them in the so/dll list any maybe command-line output but this is far from ideal.  A little separate section gives more clarity.
Bad JVMTI agents (and even good ones) can influence what is going on at runtime so that info should be present.

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2540873155

From sspitsyn at openjdk.org  Fri Dec 13 12:03:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Dec 2024 12:03:41 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v3]
In-Reply-To: <TKdlXH8_UzaoVg2x-rR40kzg2mG-Tu-lK4grf2hiVE0=.448d77f7-14a4-4d11-8e57-bbe80f61135c@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <TKdlXH8_UzaoVg2x-rR40kzg2mG-Tu-lK4grf2hiVE0=.448d77f7-14a4-4d11-8e57-bbe80f61135c@github.com>
Message-ID: <88OxcaZj_9sMZWqnW6UxWrnF9uxHS1cby_FlwkQsQ1E=.7b915fb8-1c46-42f2-933f-3369da85cec6@github.com>

On Wed, 11 Dec 2024 21:56:20 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
>> 
>> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
>> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated comment

The fix looks good modulo a couple of nits.

src/hotspot/share/services/attachListener.cpp line 670:

> 668:     // for v1 also name/arguments should not exceed name_length_max/arg_length_max.
> 669:     if (strlen(name()) > AttachOperation::name_length_max) {
> 670:       log_error(attach)("Failed to read request: name is too long");

Nit: I'd suggest to be more specific: "Failed to read request: attach operation name is too long"

src/hotspot/share/services/attachListener.hpp line 238:

> 236:   virtual void complete(jint result, bufferedStream* result_stream) = 0;
> 237: 
> 238:   class ReplyWriter; //forward declaration

Nit: The comment should start with a space.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22223#pullrequestreview-2502115945
PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1883819157
PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1883821145

From mbaesken at openjdk.org  Fri Dec 13 12:18:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 12:18:13 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  simplify coding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/fa422ce3..fa960c86

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

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

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

From mdoerr at openjdk.org  Fri Dec 13 14:57:39 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Dec 2024 14:57:39 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

Nice enhancement! Could you add an example output to the description, please?

src/hotspot/share/runtime/os.cpp line 1144:

> 1142:       if (pathinfo == nullptr) pathinfo = "none";
> 1143:       // jplis output too?
> 1144:       st->print_cr("%s path:%s, %s, %s %s %s options:%s", agent->name(), pathinfo, loadinfo, initinfo, dyninfo, instrumentinfo, optionsinfo);

I think the spaces can be improved by removing them between the "%s"s and added them to the Strings above.

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

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2502484830
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884056284

From stuefe at openjdk.org  Fri Dec 13 15:32:48 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Dec 2024 15:32:48 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v17]
In-Reply-To: <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
Message-ID: <KR6wevG2-AXL5qCkPId2Okppt6FHxelDwsGAZLbHgQ8=.2c26abab-1abe-4db7-bb0f-37af20b2afc4@github.com>

On Tue, 10 Dec 2024 12:41:00 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'openjdk:master' into pr_macos_system_dump
>  - fix crash due to uninitilized pointer
>  - whitespace error
>  - changes from revue
>  - add constant
>  - fix whitespace
>  - combine like 128MB regions
>  - fix trailing whitesdpae errors
>  - latest cleanup, get rid of dll info
>  - change format strings to display all digits properly
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/a6277bb5...c5cb0f97

Still good. Ship it!

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2502562473

From stuefe at openjdk.org  Fri Dec 13 15:40:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Dec 2024 15:40:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <mSjWLLsXo-jg442n7pnlh3VTeaCAPTWqEcNVAtvqXzs=.985396b3-415d-400d-a532-70ce2e5beccf@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

Looks fine, two bikeshedding nits.

I approve now, up to you if you take my suggestions.

src/hotspot/share/runtime/os.cpp line 1133:

> 1131:     const JvmtiAgent* agent = it.next();
> 1132:     if (agent != nullptr) {
> 1133:       if (first_agent) st->print_cr("JVMTI agents:");

if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; that could be also an error.

src/hotspot/share/runtime/os.cpp line 1138:

> 1136:       const char* instrumentinfo = agent->is_instrument_lib() ? "instrumentlib" : "";
> 1137:       const char* loadinfo = agent->is_loaded() ? "loaded" : "not loaded";
> 1138:       const char* initinfo = agent->is_initialized() ? "initialized" : "not initialized";

I would just print these as flags, its clearer and simpler to print. E.g.

"myagent path:  mylib.so dynamic:1 loaded:1 instrument_lib:0 initialized:1 xxx options xxx"

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2502573370
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884116576
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884113414

From mbaesken at openjdk.org  Fri Dec 13 15:54:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 15:54:41 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
 <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>
Message-ID: <ITylSpVnpF0aasfmCu0CdC2dkbVZRAYMFKvZ6TjXnEo=.624504e0-83c5-4eb2-83e6-dfd3f76b8621@github.com>

On Fri, 13 Dec 2024 14:54:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Nice enhancement! Could you add an example output to the description, please?

Currently it looks like this


JVMTI agents:
asyncProfiler path:none, loaded, initialized   options:start,flat=10000,interval=50us,traces=1,event=wall,loglevel=none


(example is from a JVM started with async-profiler   :  `images/jdk/bin/java -agentlib:asyncProfiler=start,flat=10000,interval=50us,traces=1,event=wall,loglevel=none   ....`  )

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2541746148

From mbaesken at openjdk.org  Fri Dec 13 16:00:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 16:00:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

>if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; >that could be also an error.

Maybe after the while loop something like this ?


  bool first_agent = true;
  while (it.has_next()) {
      ...
  }
  **if (first_agent) st->print_cr("JVMTI agents: none");**

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2541756666

From duke at openjdk.org  Fri Dec 13 16:33:44 2024
From: duke at openjdk.org (duke)
Date: Fri, 13 Dec 2024 16:33:44 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v17]
In-Reply-To: <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
Message-ID: <I5co-SEPD7D4_8dBE2Fda5RJ1AIJnDZgp820srXhQ6Q=.51cd6bd1-d7ac-4b30-bdf3-05ff20775b27@github.com>

On Tue, 10 Dec 2024 12:41:00 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This is a port of #16301  to macOS.
>> 
>> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
>> 
>> The System.map tests are also reworked to be cleaner for the three implementations.
>> 
>> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
>> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)
>
> Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'openjdk:master' into pr_macos_system_dump
>  - fix crash due to uninitilized pointer
>  - whitespace error
>  - changes from revue
>  - add constant
>  - fix whitespace
>  - combine like 128MB regions
>  - fix trailing whitesdpae errors
>  - latest cleanup, get rid of dll info
>  - change format strings to display all digits properly
>  - ... and 25 more: https://git.openjdk.org/jdk/compare/a6277bb5...c5cb0f97

@stooke 
Your change (at version c5cb0f971ac439cc018417d4246e5808389cea0f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2541817843

From stooke at openjdk.org  Fri Dec 13 16:33:45 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Fri, 13 Dec 2024 16:33:45 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v17]
In-Reply-To: <gNUR0pCkH8feTjksG3er-8KJ7-LbPtUhiFo8ThM3CjY=.fea27b19-dc3a-4424-b114-67a63b4aa11b@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <mh2ZnVihsHk2yvlyNlUGgH_dVRMqCvscr7pYjj5Ha20=.eae7aad2-04c4-4980-ac41-315ec8f7bcb1@github.com>
 <gNUR0pCkH8feTjksG3er-8KJ7-LbPtUhiFo8ThM3CjY=.fea27b19-dc3a-4424-b114-67a63b4aa11b@github.com>
Message-ID: <Co_vYUpDMf530DNo2iV72PtS4rbuvrq8f5r6KGOL7U8=.1165e780-b913-4d97-a29b-3d69609429ad@github.com>

On Thu, 12 Dec 2024 19:46:37 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

>> Simon Tooke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
>> 
>>  - Merge branch 'openjdk:master' into pr_macos_system_dump
>>  - fix crash due to uninitilized pointer
>>  - whitespace error
>>  - changes from revue
>>  - add constant
>>  - fix whitespace
>>  - combine like 128MB regions
>>  - fix trailing whitesdpae errors
>>  - latest cleanup, get rid of dll info
>>  - change format strings to display all digits properly
>>  - ... and 25 more: https://git.openjdk.org/jdk/compare/a6277bb5...c5cb0f97
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 352:
> 
>> 350:       break;
>> 351:     }
>> 352:     ::bzero(&region_info_with_path, sizeof(region_info_with_path));
> 
> Should we use memset instead?

A very good question!  Changing it now would invalidate the reviews, unfortunately.  Portability is not a concern here as it's for macOS only.  Since bzero only ever zeros memory, it _can_ be slightly faster: [one discussion](https://fdiv.net/2009/01/14/memset-vs-bzero-ultimate-showdown).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1884184636

From wkemper at openjdk.org  Fri Dec 13 17:50:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 17:50:01 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode
 is enabled [v2]
In-Reply-To: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
Message-ID: <KS59dO7fkjERqxqAdcqMunTYOFucfSZUDeUyfMqN5HY=.05af9e29-a8c5-4085-92b7-95f76b233623@github.com>

> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22695/files
  - new: https://git.openjdk.org/jdk/pull/22695/files/57526d7f..2eb4ad12

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

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

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

From lmesnik at openjdk.org  Fri Dec 13 17:59:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 17:59:36 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode
 is enabled [v2]
In-Reply-To: <KS59dO7fkjERqxqAdcqMunTYOFucfSZUDeUyfMqN5HY=.05af9e29-a8c5-4085-92b7-95f76b233623@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
 <KS59dO7fkjERqxqAdcqMunTYOFucfSZUDeUyfMqN5HY=.05af9e29-a8c5-4085-92b7-95f76b233623@github.com>
Message-ID: <vT7RzTfvtQlEj4HXC1J4eAStDXJ_6h2AFLoIpVpRJxM=.b0e913d3-5761-47bd-9488-0933054ee8ea@github.com>

On Fri, 13 Dec 2024 17:50:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright date

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22695#pullrequestreview-2502846643

From wkemper at openjdk.org  Fri Dec 13 18:16:41 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 18:16:41 GMT
Subject: Integrated: 8346051: MemoryTest fails when Shenandoah's generational
 mode is enabled
In-Reply-To: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
References: <Xo_RpsbWff5yWKtjA2N8mKJVcy0Szmqko_aD-uXP0hw=.40cd76ab-c16b-4366-9db3-913f45aadb04@github.com>
Message-ID: <iY4IcY8GaC5hOX2LYWkDkByKy9aqZrD41_8awJupg0E=.3aa38dbd-93cb-4c95-82dd-ad8a661e4649@github.com>

On Thu, 12 Dec 2024 00:01:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This test makes assertions about the number of gc manager beans and the number of memory pools. The generational mode for Shenandoah adds another memory pool.

This pull request has now been integrated.

Changeset: cfa04d31
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cfa04d31ddff49cbf5dfdfedd61264d5556a283c
Stats:     16 lines in 1 file changed: 12 ins; 0 del; 4 mod

8346051: MemoryTest fails when Shenandoah's generational mode is enabled

Reviewed-by: lmesnik, ysr

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

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

From kevinw at openjdk.org  Fri Dec 13 19:51:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 19:51:09 GMT
Subject: RFR: 8241865: sun/management/jdp tests fail (Timed out waiting for JDP
 packet)
Message-ID: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>

This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".

Forcing it to require any other OS version looks good in my testing.

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

Commit messages:
 - remove uncalled misspelled method
 - (C)
 - update
 - update
 - 8241865: sun/management/jdp tests fail (Timed out waiting for JDP packet)

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

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

From kevinw at openjdk.org  Fri Dec 13 19:51:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 19:51:09 GMT
Subject: RFR: 8241865: sun/management/jdp tests fail (Timed out waiting for
 JDP packet)
In-Reply-To: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
References: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
Message-ID: <Umysv5AlUuJeG0a6A1KEr6lxIwUYyrdd9Gkg_SVFrDc=.4d89debd-b04b-41c5-90b9-81aa7967b3ff@github.com>

On Fri, 13 Dec 2024 18:58:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".
> 
> Forcing it to require any other OS version looks good in my testing.

There was a Linux x64 failure a few years back, but since un-problemlisting in August 2024, macos aarch64 is where we are seeing failures.  A batch of 20 run will generally see a few failures on that platform and nowhere else.

I did some experiments with other fixes such as long timeouts, retrying the test, pausing and retrying the test.
But the OSX 15.0.1 failure is not solved by any of these.  Requiring any other OS version seems better than problemlisting, and means we do run this test on multiple other MacOSX aarch64 versions.

While here:

Some typos and formatting changes.

When handling SocketTimeoutException, don't capitalise the method as "onSocketTimeOut()", make the "Timeout" case consistent (which made my searching easier).

Remove the ' quotes from the loggers, that looks strange in the logs, probably unintentional.  Output is now like:
2024-12-12 18:39:50 FINE    Pause in between packets is: 1 seconds.
2024-12-12 18:39:50 FINE    Timeout set to 20 seconds.

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

PR Comment: https://git.openjdk.org/jdk/pull/22742#issuecomment-2542168289

From kevinw at openjdk.org  Fri Dec 13 19:54:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 19:54:36 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <D3XilRB2AhywILKKBc_fIPJOYegKE2qEFYIOIeYO8P4=.36e9dd64-1455-4c3d-91a8-5e5e18171ed0@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Unnecessary duplication of small utility method.

1
src/java.management/share/classes/com/sun/jmx/mbeanserver/Util.java:      public static ObjectName newObjectName(String string)

This method uses new ObjectName(string).

2
src/java.management/share/classes/sun/management/Util.java  public static ObjectName newObjectName(String name)

This one uses ObjectName.getInstance(name), which is defined in ObjectName.java to do: return new ObjectName(name).
So these two are equivalent.

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

PR Comment: https://git.openjdk.org/jdk/pull/22681#issuecomment-2542184977

From lmesnik at openjdk.org  Fri Dec 13 20:01:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 20:01:36 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <IpdjmpCMop4d9n5kndciEk1KxJTVPRiOYPMNjvsBwtc=.56733690-06c0-4d24-8d08-60299269034d@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

> Unnecessary duplication of small utility method.

> This one uses ObjectName.getInstance(name), which is defined in ObjectName.java to do: return new ObjectName(name). So these two are equivalent.

Sorry, I mistaken with signature. 
Thanks for describing.

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

PR Comment: https://git.openjdk.org/jdk/pull/22681#issuecomment-2542199902

From kevinw at openjdk.org  Fri Dec 13 20:01:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 20:01:37 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <IpdjmpCMop4d9n5kndciEk1KxJTVPRiOYPMNjvsBwtc=.56733690-06c0-4d24-8d08-60299269034d@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
 <IpdjmpCMop4d9n5kndciEk1KxJTVPRiOYPMNjvsBwtc=.56733690-06c0-4d24-8d08-60299269034d@github.com>
Message-ID: <JAnzd_Z5IJR9Aszx0rC4BtiimVOCYALrioh27X3yKzE=.e4a0ac1e-68f4-41b4-83e8-6b2fda302bab@github.com>

On Fri, 13 Dec 2024 19:57:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Thanks for describing.

Thanks for confirming. The fewer of these methods the better!

> src/java.management/share/classes/javax/management/ObjectName.java line 1225:
> 
>> 1223:         if (name.getClass().equals(ObjectName.class))
>> 1224:             return name;
>> 1225:         return sun.management.Util.newObjectName(name.getSerializedNameString());
> 
> The newObjectName methods are different in 2 Utils.
> The share/classes/sun/management/Util.java is
> 
>   45   ?     public static ObjectName newObjectName(String name) {
>   46   ?         try {
>   47   ?             return ObjectName.getInstance(name);
>   48   ?         } catch (MalformedObjectNameException e) {
>   49   ?             throw new IllegalArgumentException(e);
>   50   ?         }
>   51   ?     }
> 
> Isn't it infinite recursion?

Right, they are different, but one uses "new", and one calls a newInstance method which uses "new", so they are really the same.  Daniel's note in the JBS bug hints that there may have been an idea to do some caching in getInstance, which has not as yet been implemented.

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

PR Comment: https://git.openjdk.org/jdk/pull/22681#issuecomment-2542205911
PR Review Comment: https://git.openjdk.org/jdk/pull/22681#discussion_r1884463700

From lmesnik at openjdk.org  Fri Dec 13 20:08:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 13 Dec 2024 20:08:37 GMT
Subject: RFR: 8345987: java.management has two Util.newObjectName methods
 (remove one) [v2]
In-Reply-To: <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
 <8_2gc7B4E6QVqWTrYxtg3q_lEQqSs6Bnmor9fb7edSE=.804c5c8b-43d8-455e-b405-e1f3c404ea6a@github.com>
Message-ID: <zrV2j-qNDrPl2voX8wKMHm7FvJd2kPx6XM_hnNQLQhA=.dc9c2a9c-8a6a-40e3-8fb9-02becb4da1e8@github.com>

On Thu, 12 Dec 2024 09:54:03 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().
>
> 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 three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8345987_newObjectName
>  - static imports
>  - 8345987: java.management has two Util.newObjectName methods (remove one)

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22681#pullrequestreview-2503169293

From fparain at openjdk.org  Fri Dec 13 20:31:42 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 13 Dec 2024 20:31:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v3]
In-Reply-To: <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>
Message-ID: <GYNIY0E_RAnMEZ4BR6qdKmOnGBTg8IxTKmEY4ihul2I=.fe725660-c358-4ef0-8185-8ddb985c65e4@github.com>

On Thu, 12 Dec 2024 14:51:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into modifiers
>  - remove "jvm support"
>  - 8345678: compute_modifiers should not be in create_mirror

LGTM

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2503199455

From kevinw at openjdk.org  Fri Dec 13 20:41:45 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 20:41:45 GMT
Subject: Integrated: 8345987: java.management has two Util.newObjectName
 methods (remove one)
In-Reply-To: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
References: <4YL3ARQW81vh2G2-yGVJWMyYFOYkRoAKXOO9Cve2hZE=.568ae0cc-7809-4e06-97ad-2597ed9da139@github.com>
Message-ID: <ge6w4pII5d9hCly1rcRetXaHG9RWX_j2NIMso18uOJg=.ff62f75a-6773-4d5b-aad2-85f1a40abd15@github.com>

On Wed, 11 Dec 2024 13:55:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Unnecessary duplication of small utility method.  There should be only one Util.newObjectName().

This pull request has now been integrated.

Changeset: e7fc0eb5
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7fc0eb522f14ee28ac40cf89268767cb7b6dfcf
Stats:     18 lines in 5 files changed: 2 ins; 9 del; 7 mod

8345987: java.management has two Util.newObjectName methods (remove one)

Reviewed-by: cjplummer, amenkov, lmesnik

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

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

From cjplummer at openjdk.org  Fri Dec 13 20:42:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 13 Dec 2024 20:42:35 GMT
Subject: RFR: 8241865: sun/management/jdp tests fail (Timed out waiting for
 JDP packet)
In-Reply-To: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
References: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
Message-ID: <D5P6UjLrDfQ1FhH58pJNJrTNBJERsnt-bvtfmxWkeU0=.74e9c5c6-9c7a-4200-b0c7-986687766cbd@github.com>

On Fri, 13 Dec 2024 18:58:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".
> 
> Forcing it to require any other OS version looks good in my testing.

test/jdk/sun/management/jdp/JdpDefaultsTest.java line 33:

> 31:  * @test JdpDefaultsTest
> 32:  * @summary Assert that we can read JDP packets from a multicast socket connection, on default IP and port.
> 33:  * @requires os.version != "Mac OS X 15.0.1 (aarch64)"

Unless there is a known reason why this test cannot run on this platform, this is probably not the appropriate fix here. I'd suggest keeping the CR open and problem listing for macosx-aarch64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22742#discussion_r1884519109

From cjplummer at openjdk.org  Fri Dec 13 20:52:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 13 Dec 2024 20:52:36 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest
In-Reply-To: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
Message-ID: <L498YGF0CPjas11S7B47UXihqYRv9eqtkcjc1U1Puaw=.78a4ad56-18a8-46a3-bd04-adf857b0c67f@github.com>

On Fri, 13 Dec 2024 02:21:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix adds handling of the errors to get information for analysis.

Changes requested by cjplummer (Reviewer).

test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 259:

> 257:                     + "' of " + classfileBuffer.length + " bytes.");
> 258:             } catch (Throwable t) {
> 259:                 // try to log, save the error for handling by main thread if the logging fails

Suggestion:

                // Try to log. Save the error for handling by main thread if the logging fails.

test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 261:

> 259:                 // try to log, save the error for handling by main thread if the logging fails
> 260:                 try {
> 261:                     transformerException.printStackTrace();

Isn't this suppose to be `t.printStackTrace()`?

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

PR Review: https://git.openjdk.org/jdk/pull/22727#pullrequestreview-2503225089
PR Review Comment: https://git.openjdk.org/jdk/pull/22727#discussion_r1884527770
PR Review Comment: https://git.openjdk.org/jdk/pull/22727#discussion_r1884527374

From sspitsyn at openjdk.org  Fri Dec 13 20:57:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Dec 2024 20:57:46 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases
Message-ID: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@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).

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

Commit messages:
 - fixed trailing space in jvmtiEnvBase.hpp
 - 8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

Changes: https://git.openjdk.org/jdk/pull/22744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346143
  Stats: 132 lines in 10 files changed: 116 ins; 3 del; 13 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 amenkov at openjdk.org  Fri Dec 13 21:22:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:22:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
 <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>
Message-ID: <sGeS9qupzQg4RfWCZcXSPaMixW7Q1SgcOZ0QBMlApXc=.8998bf58-f753-4246-ac39-b000ff806c86@github.com>

On Fri, 13 Dec 2024 15:57:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; >that could be also an error.
> 
> Maybe after the while loop something like this ?
> 
> ```
>   bool first_agent = true;
>   while (it.has_next()) {
>       ...
>   }
>   **if (first_agent) st->print_cr("JVMTI agents: none");**
> ```

You can do it before the loop:

if (it.has_next()) {
  st->print_cr("JVMTI agents:");
} else {
  st->print_cr("JVMTI agents: none");
}

and get rid of `first_agent` variable

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2542400056

From amenkov at openjdk.org  Fri Dec 13 21:29:14 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:29:14 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v4]
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <vJA2HSjb4Na3xCEwuCLItgei35-zQSiTGhNhpzvydLw=.6957942f-94fa-43c5-a5a0-71d8bcef5323@github.com>

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22223/files
  - new: https://git.openjdk.org/jdk/pull/22223/files/27bb3c43..24ab7563

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

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

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

From amenkov at openjdk.org  Fri Dec 13 21:29:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:29:15 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v3]
In-Reply-To: <88OxcaZj_9sMZWqnW6UxWrnF9uxHS1cby_FlwkQsQ1E=.7b915fb8-1c46-42f2-933f-3369da85cec6@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <TKdlXH8_UzaoVg2x-rR40kzg2mG-Tu-lK4grf2hiVE0=.448d77f7-14a4-4d11-8e57-bbe80f61135c@github.com>
 <88OxcaZj_9sMZWqnW6UxWrnF9uxHS1cby_FlwkQsQ1E=.7b915fb8-1c46-42f2-933f-3369da85cec6@github.com>
Message-ID: <K0mRrnzUOUzTy6QbEcaw7atUCr4tCue79n3ukSuVGqs=.5fa9df49-1b60-41fb-97f6-f9cd3aee4e9a@github.com>

On Fri, 13 Dec 2024 11:50:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated comment
>
> src/hotspot/share/services/attachListener.cpp line 670:
> 
>> 668:     // for v1 also name/arguments should not exceed name_length_max/arg_length_max.
>> 669:     if (strlen(name()) > AttachOperation::name_length_max) {
>> 670:       log_error(attach)("Failed to read request: name is too long");
> 
> Nit: I'd suggest to be more specific: "Failed to read request: attach operation name is too long"

There is "attach" in the log prefix, so I made it "Failed to read request: operation name is too long"
And updated similar logging for arguments several lines below

> src/hotspot/share/services/attachListener.hpp line 238:
> 
>> 236:   virtual void complete(jint result, bufferedStream* result_stream) = 0;
>> 237: 
>> 238:   class ReplyWriter; //forward declaration
> 
> Nit: The comment should start with a space.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1884559859
PR Review Comment: https://git.openjdk.org/jdk/pull/22223#discussion_r1884560028

From coleenp at openjdk.org  Fri Dec 13 21:37:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 13 Dec 2024 21:37:55 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

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

  Removed comment about compute_modifiers().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/a0792dff..ef393005

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

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

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

From amenkov at openjdk.org  Fri Dec 13 21:51:10 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:51:10 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v2]
In-Reply-To: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
Message-ID: <tV54bhKwHH50XCn4FKqM2IcyQ0BJonuk0Dr5pFdtWGs=.dee5c3a6-e3aa-4753-8d77-deaaded8f716@github.com>

> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix adds handling of the errors to get information for analysis.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22727/files
  - new: https://git.openjdk.org/jdk/pull/22727/files/7665ba02..2cbdc9b9

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

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

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

From amenkov at openjdk.org  Fri Dec 13 21:53:36 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:53:36 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v2]
In-Reply-To: <L498YGF0CPjas11S7B47UXihqYRv9eqtkcjc1U1Puaw=.78a4ad56-18a8-46a3-bd04-adf857b0c67f@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
 <L498YGF0CPjas11S7B47UXihqYRv9eqtkcjc1U1Puaw=.78a4ad56-18a8-46a3-bd04-adf857b0c67f@github.com>
Message-ID: <XVg18mCUVxqs4O8PCMno5UN494UKL1a9CojljSEAUoU=.dbe887ea-2444-4610-8f90-b38849c16201@github.com>

On Fri, 13 Dec 2024 20:49:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 259:
> 
>> 257:                     + "' of " + classfileBuffer.length + " bytes.");
>> 258:             } catch (Throwable t) {
>> 259:                 // try to log, save the error for handling by main thread if the logging fails
> 
> Suggestion:
> 
>                 // Try to log. Save the error for handling by main thread if the logging fails.

Done

> test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 261:
> 
>> 259:                 // try to log, save the error for handling by main thread if the logging fails
>> 260:                 try {
>> 261:                     transformerException.printStackTrace();
> 
> Isn't this suppose to be `t.printStackTrace()`?

Good catch!
Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22727#discussion_r1884580477
PR Review Comment: https://git.openjdk.org/jdk/pull/22727#discussion_r1884580327

From coleenp at openjdk.org  Fri Dec 13 22:29:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 13 Dec 2024 22:29:45 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM
Message-ID: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>

This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.

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

Commit messages:
 - 8337016: serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace OOM
 - 8337016: serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace OOM

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

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

From kevinw at openjdk.org  Fri Dec 13 22:40:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 13 Dec 2024 22:40:37 GMT
Subject: RFR: 8241865: sun/management/jdp tests fail (Timed out waiting for
 JDP packet)
In-Reply-To: <D5P6UjLrDfQ1FhH58pJNJrTNBJERsnt-bvtfmxWkeU0=.74e9c5c6-9c7a-4200-b0c7-986687766cbd@github.com>
References: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
 <D5P6UjLrDfQ1FhH58pJNJrTNBJERsnt-bvtfmxWkeU0=.74e9c5c6-9c7a-4200-b0c7-986687766cbd@github.com>
Message-ID: <RU6a9E2fMU6bpHRtA-3y1Nhy7Z4ol_OYXKn_0w0C2oU=.4841d82e-6359-4329-85a3-081423e3c185@github.com>

On Fri, 13 Dec 2024 20:40:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".
>> 
>> Forcing it to require any other OS version looks good in my testing.
>
> test/jdk/sun/management/jdp/JdpDefaultsTest.java line 33:
> 
>> 31:  * @test JdpDefaultsTest
>> 32:  * @summary Assert that we can read JDP packets from a multicast socket connection, on default IP and port.
>> 33:  * @requires os.version != "Mac OS X 15.0.1 (aarch64)"
> 
> Unless there is a known reason why this test cannot run on this platform, this is probably not the appropriate fix here. I'd suggest keeping the CR open and problem listing for macosx-aarch64.

Ok, I was thinking about debating that after many failures on 15.0.1 and nothing else... But just now we see one on "Mac OS X 12.7.1 (aarch64)" so problemlisting for macosx-aarch64 generally now seems right! (will update)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22742#discussion_r1884615620

From cjplummer at openjdk.org  Fri Dec 13 23:00:41 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 13 Dec 2024 23:00:41 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v2]
In-Reply-To: <tV54bhKwHH50XCn4FKqM2IcyQ0BJonuk0Dr5pFdtWGs=.dee5c3a6-e3aa-4753-8d77-deaaded8f716@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
 <tV54bhKwHH50XCn4FKqM2IcyQ0BJonuk0Dr5pFdtWGs=.dee5c3a6-e3aa-4753-8d77-deaaded8f716@github.com>
Message-ID: <K9Glpo-NBwxSzfR6sXSRyfjUQkCCbYnPBcXmuDlmUkM=.c408e1b6-85af-4318-9afb-f772b68151e7@github.com>

On Fri, 13 Dec 2024 21:51:10 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> The fix adds handling of the errors to get information for analysis.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Copyright needs updating. Otherwise looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22727#pullrequestreview-2503366213

From amenkov at openjdk.org  Fri Dec 13 23:07:53 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 23:07:53 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v3]
In-Reply-To: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
Message-ID: <kRZUdAiblUOlC_xKUY84P8MxtwiM2rcdN23PlNC5qXA=.dd1012a2-4a23-471b-af71-33e49ac01c45@github.com>

> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix adds handling of the errors to get information for analysis.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  copyright update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22727/files
  - new: https://git.openjdk.org/jdk/pull/22727/files/2cbdc9b9..012579f1

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

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

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

From cjplummer at openjdk.org  Fri Dec 13 23:53:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 13 Dec 2024 23:53:35 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v3]
In-Reply-To: <kRZUdAiblUOlC_xKUY84P8MxtwiM2rcdN23PlNC5qXA=.dd1012a2-4a23-471b-af71-33e49ac01c45@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
 <kRZUdAiblUOlC_xKUY84P8MxtwiM2rcdN23PlNC5qXA=.dd1012a2-4a23-471b-af71-33e49ac01c45@github.com>
Message-ID: <gHPpaeNpSw-roLgRcMcgEW0mW4q3KAAxRNj8313v46Y=.8ad3ecf3-9771-4d27-ae2c-622983e2a4e7@github.com>

On Fri, 13 Dec 2024 23:07:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> The fix adds handling of the errors to get information for analysis.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright update

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22727#pullrequestreview-2503400302

From stooke at openjdk.org  Sat Dec 14 06:16:45 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Sat, 14 Dec 2024 06:16:45 GMT
Subject: Integrated: 8319875: Add macOS implementation for jcmd System.map
In-Reply-To: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
Message-ID: <PGS_mkfNNAwGopBT_yyBz8bspaNjfYX7vRBAl0ieHvE=.d0ebb368-92a8-45a2-808d-53005ac77679@github.com>

On Wed, 11 Sep 2024 18:22:00 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This is a port of #16301  to macOS.
> 
> System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit.
> 
> The System.map tests are also reworked to be cleaner for the three implementations.
> 
> [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt)
> [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt)

This pull request has now been integrated.

Changeset: 3b9de117
Author:    Simon Tooke <stooke at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b9de117e83a7875df7fd2ddcc9d896f027e2c92
Stats:     583 lines in 9 files changed: 505 ins; 40 del; 38 mod

8319875: Add macOS implementation for jcmd System.map

Reviewed-by: stuefe, szaldana

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

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

From jwaters at openjdk.org  Sun Dec 15 06:29:45 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 15 Dec 2024 06:29:45 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: <YYUfF1Ck4c4Zi8JWfWnX8oCA7BMEGzKkR5DxDFLz2Iw=.d78e9fe3-4f61-4da5-ae36-fbd634b89837@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

Oh, haha I was referring to the other Pull Requests that clean up the unused code in other parts of the JDK

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2543470498

From dholmes at openjdk.org  Sun Dec 15 21:42:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 15 Dec 2024 21:42:36 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM
In-Reply-To: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
Message-ID: <Mvn03dyWeqtZIF6Tzb32yo3_6sfiPS-8cjeobfxvpaw=.ff52d107-ad7c-4f5d-a1dc-ad9da09955e1@github.com>

On Fri, 13 Dec 2024 22:25:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.

Changes requested by dholmes (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java line 38:

> 36:  */
> 37: 
> 38: // MaxMetaspaceSize=23m allows InMemoryJavaCompiler to load even if CDS is off.

Suggestion:

// MaxMetaspaceSize=25m allows InMemoryJavaCompiler to load even if CDS is off.

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

PR Review: https://git.openjdk.org/jdk/pull/22746#pullrequestreview-2504739971
PR Review Comment: https://git.openjdk.org/jdk/pull/22746#discussion_r1885884633

From mbaesken at openjdk.org  Mon Dec 16 08:16:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 08:16:40 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <MY-t3kg0dmnROtWTNAEhiXKrXCUuozmHD3-L8aCkRyw=.a953e805-1dcb-461c-b104-f6b5757e819e@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

When printing  'JVMTI agents: none' , should I maybe better iterate  `JvmtiAgentList::all() `  to get the xrun agents as well and be sure that there are  _really_ none ?
Unfortunately `JvmtiAgentList::all() `  is private , any objections making it public ?  Otherwise we probably need to call  2 iterations (agents() and xrun_agents()).

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2544878498

From stefank at openjdk.org  Mon Dec 16 10:22:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 10:22:05 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
Message-ID: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>

[JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.

serviceability/dcmd/vm/SystemDumpMapTest.java
serviceability/dcmd/vm/SystemMapTest.java

test SystemMapTest.jmx(): failure
java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
at SystemMapTest.run(SystemMapTest.java:50)
at SystemMapTest.jmx(SystemMapTest.java:57)

The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.

@stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

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

Commit messages:
 - 8346248: serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on macos-aarch64

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

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

From kevinw at openjdk.org  Mon Dec 16 10:32:45 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 10:32:45 GMT
Subject: RFR: 8346257: Problemlist jdp tests for macosx-aarch64
Message-ID: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>

Fairly frequent failures on macosx-aarch64.  For a while it was always on 15.0.1, but now also seen on "Mac OS X 12.7.1 (aarch64)", so this should be problemlisted for macosx-aarch64.

There are existing entries for aix, and the ProblemList file says it only wants one line per test. 

Trivial change tested in CI which shows that sun/management/jdp/JdpOffTest.java still runs on macosx-aarch64.

Tests failing:
sun/management/jdp/JdpSpecificAddressTest.java
sun/management/jdp/JdpDefaultsTest.java
sun/management/jdp/JdpJmxRemoteDynamicPortTest.java

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

Commit messages:
 - one line per test
 - 8346257: Problemlist jdp tests for macosx-aarch64

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

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

From kevinw at openjdk.org  Mon Dec 16 11:30:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 11:30:39 GMT
Subject: RFR: 8241865: sun/management/jdp tests fail (Timed out waiting for
 JDP packet) (macosx-aarch64)
In-Reply-To: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
References: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
Message-ID: <rXDmnCAbJnPB3A9UIPMtqPw69dQkWMSWeoCmPNuYTTI=.095cdb0a-b7e9-4176-a751-3d540c3c228c@github.com>

On Fri, 13 Dec 2024 18:58:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".
> 
> Forcing it to require any other OS version looks good in my testing.

Closing this and following up with:

Problemlisting: https://github.com/openjdk/jdk/pull/22758

Other JDP test tidyups: https://github.com/openjdk/jdk/pull/22761

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

PR Comment: https://git.openjdk.org/jdk/pull/22742#issuecomment-2545363247

From kevinw at openjdk.org  Mon Dec 16 11:30:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 11:30:40 GMT
Subject: Withdrawn: 8241865: sun/management/jdp tests fail (Timed out waiting
 for JDP packet) (macosx-aarch64)
In-Reply-To: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
References: <h2gRp3uUntfTjenMjiH0L5iFJ2Cs3sacZCcZ4Y4uFJY=.958f23fd-0a0e-4542-9eed-88c34f85cf9e@github.com>
Message-ID: <-r4kxdjoROaxmQAcLaaMlSHE3zN9oikIDBtKaSG1Ba8=.e004c79c-4a68-4b69-a8cc-50eda8709422@github.com>

On Fri, 13 Dec 2024 18:58:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been noisy lately, and all the failures have been on "Mac OS X 15.0.1 (aarch64)".
> 
> Forcing it to require any other OS version looks good in my testing.

This pull request has been closed without being integrated.

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

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

From kevinw at openjdk.org  Mon Dec 16 11:59:04 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 11:59:04 GMT
Subject: RFR: 8346261: Cleanup in JDP tests
Message-ID: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>

Simple test update to fix some typos and formatting changes, seen while investigating and testing for JDK-8241865.

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

Commit messages:
 - 8346261: Cleanup in JDP tests

Changes: https://git.openjdk.org/jdk/pull/22761/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346261
  Stats: 37 lines in 10 files changed: 5 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/22761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22761/head:pull/22761

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

From mbaesken at openjdk.org  Mon Dec 16 12:45:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 12:45:54 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v5]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <vHGv_TCzR2kDTP-m-UCTmWckLLf_I1gK_FcE9fAWZMo=.28b9a379-f9a5-4a91-8767-c3a02435c8c4@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust output a bit, print xrun agents  too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/fa960c86..48b04980

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

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

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

From mbaesken at openjdk.org  Mon Dec 16 12:53:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 12:53:52 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust spaces in output

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/48b04980..3bf026ad

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

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

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

From stooke at openjdk.org  Mon Dec 16 13:23:37 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 16 Dec 2024 13:23:37 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
Message-ID: <92UPYQZAD_0LM2KRZzeULkRM4faASyR91DxSbBTt5hE=.ee4b30b1-19d7-4087-8144-02bf81f9e6d5@github.com>

On Mon, 16 Dec 2024 10:17:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
> 
> serviceability/dcmd/vm/SystemDumpMapTest.java
> serviceability/dcmd/vm/SystemMapTest.java
> 
> test SystemMapTest.jmx(): failure
> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
> at SystemMapTest.run(SystemMapTest.java:50)
> at SystemMapTest.jmx(SystemMapTest.java:57)
> 
> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
> 
> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

(disclaimer - I am not a reviewer)

@stefank this looks right to me.  As part of the final refactoring, "-shared" was removed from the output, but the ZGC portion of the test was not updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/22759#issuecomment-2545618743

From eosterlund at openjdk.org  Mon Dec 16 13:46:49 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 16 Dec 2024 13:46:49 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
Message-ID: <QWRZmvHoLd66BygTNs8vKJ4kp9YQJpbPMjLqkmGjEV0=.a33ac6ac-3780-4fb5-b68f-c31b312e817f@github.com>

On Mon, 16 Dec 2024 10:17:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
> 
> serviceability/dcmd/vm/SystemDumpMapTest.java
> serviceability/dcmd/vm/SystemMapTest.java
> 
> test SystemMapTest.jmx(): failure
> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
> at SystemMapTest.run(SystemMapTest.java:50)
> at SystemMapTest.jmx(SystemMapTest.java:57)
> 
> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
> 
> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

Looks good! ...and trivial. Ship it.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22759#pullrequestreview-2506224389

From stefank at openjdk.org  Mon Dec 16 13:46:50 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 13:46:50 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <92UPYQZAD_0LM2KRZzeULkRM4faASyR91DxSbBTt5hE=.ee4b30b1-19d7-4087-8144-02bf81f9e6d5@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
 <92UPYQZAD_0LM2KRZzeULkRM4faASyR91DxSbBTt5hE=.ee4b30b1-19d7-4087-8144-02bf81f9e6d5@github.com>
Message-ID: <yDGg__jp27WXCjBqKlB9uh1-bHJr2O7uZtdTJ1BP1BE=.93fffc05-8f32-4df5-852c-8aafb3b4e531@github.com>

On Mon, 16 Dec 2024 13:20:44 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
>> 
>> serviceability/dcmd/vm/SystemDumpMapTest.java
>> serviceability/dcmd/vm/SystemMapTest.java
>> 
>> test SystemMapTest.jmx(): failure
>> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
>> at SystemMapTest.run(SystemMapTest.java:50)
>> at SystemMapTest.jmx(SystemMapTest.java:57)
>> 
>> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
>> 
>> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?
>
> (disclaimer - I am not a reviewer)
> 
> @stefank this looks right to me.  As part of the final refactoring, "-shared" was removed from the output, but the ZGC portion of the test was not updated.

@stooke Great, thanks! I'll get a Reviewer to review this and will push this ASAP.

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

PR Comment: https://git.openjdk.org/jdk/pull/22759#issuecomment-2545663911

From stefank at openjdk.org  Mon Dec 16 13:46:50 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 13:46:50 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
Message-ID: <DVSxE65X95iY0vi0oUjCHccKazLhx9gWvVQhB8USlkA=.97540d27-58b0-4685-b566-dc6e7e2d58ac@github.com>

On Mon, 16 Dec 2024 10:17:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
> 
> serviceability/dcmd/vm/SystemDumpMapTest.java
> serviceability/dcmd/vm/SystemMapTest.java
> 
> test SystemMapTest.jmx(): failure
> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
> at SystemMapTest.run(SystemMapTest.java:50)
> at SystemMapTest.jmx(SystemMapTest.java:57)
> 
> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
> 
> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22759#issuecomment-2545667010

From stefank at openjdk.org  Mon Dec 16 13:46:50 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 13:46:50 GMT
Subject: Integrated: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
Message-ID: <sTlMENfZ1qj1RtSm_fn8XEtQmsahJ0bTJZiLEFQPouM=.28fa6da6-54f1-4a2f-9669-187229ccd32c@github.com>

On Mon, 16 Dec 2024 10:17:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
> 
> serviceability/dcmd/vm/SystemDumpMapTest.java
> serviceability/dcmd/vm/SystemMapTest.java
> 
> test SystemMapTest.jmx(): failure
> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
> at SystemMapTest.run(SystemMapTest.java:50)
> at SystemMapTest.jmx(SystemMapTest.java:57)
> 
> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
> 
> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

This pull request has now been integrated.

Changeset: 45a32979
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a329790b844139010c95f981c72ad43b08369a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8346248: serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on macos-aarch64

Reviewed-by: eosterlund

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

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

From mdoerr at openjdk.org  Mon Dec 16 14:29:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Dec 2024 14:29:38 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
Message-ID: <Q_sb6J3ISEIgzdyBWCrxFKRHC42WgcuXXMkB1p33X2w=.0c2bf0bb-2ad9-4c5e-9a47-f0e7bcb90fc3@github.com>

On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces in output

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2506344138

From mbaesken at openjdk.org  Mon Dec 16 14:35:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 14:35:41 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
Message-ID: <LyH4vwK3twWbE1WpUSSF4vkG9wNOlXPunvMmjkdFiz8=.42f16bc9-42df-4bfb-99a6-7deda9a6b494@github.com>

On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces in output

Hi Martin, David, Thomas, thanks for the reviews !

(should we consider adding the JVMTI agent output to jcmd too as a separate command/option?  (but  not in this change) )

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2545786871

From stuefe at openjdk.org  Mon Dec 16 14:49:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 16 Dec 2024 14:49:43 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
Message-ID: <X1dgCEY-ULNa6wv3ndqBukesSdf3KCtRFpFXevIIIF4=.57cdf611-fecd-42ab-afd4-4e1e04ae5741@github.com>

On Mon, 16 Dec 2024 10:17:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
> 
> serviceability/dcmd/vm/SystemDumpMapTest.java
> serviceability/dcmd/vm/SystemMapTest.java
> 
> test SystemMapTest.jmx(): failure
> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
> at SystemMapTest.run(SystemMapTest.java:50)
> at SystemMapTest.jmx(SystemMapTest.java:57)
> 
> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
> 
> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?

Saw this too late. Patch looks fine. Thanks for fixing!

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

PR Comment: https://git.openjdk.org/jdk/pull/22759#issuecomment-2545822475

From stefank at openjdk.org  Mon Dec 16 15:10:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 15:10:43 GMT
Subject: RFR: 8346248:
 serviceability/dcmd/vm/{SystemMapTest.java,SystemMapTest.java} failing on
 macos-aarch64
In-Reply-To: <X1dgCEY-ULNa6wv3ndqBukesSdf3KCtRFpFXevIIIF4=.57cdf611-fecd-42ab-afd4-4e1e04ae5741@github.com>
References: <MkPWf2PmMluhDsXZcLisHiZWjG-tZ-5WK5FkH4_biDA=.17ddce8a-01ca-4db4-b9cd-dc5c0e60259e@github.com>
 <X1dgCEY-ULNa6wv3ndqBukesSdf3KCtRFpFXevIIIF4=.57cdf611-fecd-42ab-afd4-4e1e04ae5741@github.com>
Message-ID: <2xxbt_pvjSKHwCkwpMrVnGgTbU231Z-rq6GZKNVChvM=.8976cf73-922a-4e28-9ba6-b48e12f40cd0@github.com>

On Mon, 16 Dec 2024 14:47:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> [JDK-8319875](https://bugs.openjdk.org/browse/JDK-8319875) updated jcmd System.map to support macOS but the tests are now failing on macosx-aarch64 with ZGC.
>> 
>> serviceability/dcmd/vm/SystemDumpMapTest.java
>> serviceability/dcmd/vm/SystemMapTest.java
>> 
>> test SystemMapTest.jmx(): failure
>> java.lang.RuntimeException: '0x\\p{XDigit}+-0x\\p{XDigit}+ +\\d+ +[\-rwx]*/[\-rwx]* +(pvt|tsh-shared) +(0x\\p{XDigit}+|\\d+) +JAVAHEAP.*' missing from stdout/stderr
>> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:372)
>> at SystemMapTest.run(SystemMapTest.java:50)
>> at SystemMapTest.jmx(SystemMapTest.java:57)
>> 
>> The output from my runs says `tsh` and not `tsh-shared`. The following change seems to work on my machine and on macosx-aarch64 and macosx-x64 in our CI pipeline.
>> 
>> @stooke @tstuefe Do you think this looks reasonable or was there some systems that reported this as pvt-shared?
>
> Saw this too late. Patch looks fine. Thanks for fixing!

@tstuefe Thanks for the post-integration review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22759#issuecomment-2545877985

From coleenp at openjdk.org  Mon Dec 16 16:06:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 16:06:13 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM [v2]
In-Reply-To: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
Message-ID: <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>

> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.

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

  Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22746/files
  - new: https://git.openjdk.org/jdk/pull/22746/files/f4d010ee..a1d529ff

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

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

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

From larry.cable at oracle.com  Mon Dec 16 16:27:12 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 16 Dec 2024 08:27:12 -0800
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <LyH4vwK3twWbE1WpUSSF4vkG9wNOlXPunvMmjkdFiz8=.42f16bc9-42df-4bfb-99a6-7deda9a6b494@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
 <LyH4vwK3twWbE1WpUSSF4vkG9wNOlXPunvMmjkdFiz8=.42f16bc9-42df-4bfb-99a6-7deda9a6b494@github.com>
Message-ID: <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>

again what's the use case?


On 12/16/24 6:35 AM, Matthias Baesken wrote:
> On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
>
>>> We should output more information about the JVMTI agents in the hserr file.
>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    adjust spaces in output
> Hi Martin, David, Thomas, thanks for the reviews !
>
> (should we consider adding the JVMTI agent output to jcmd too as a separate command/option?  (but  not in this change) )
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2545786871


From cjplummer at openjdk.org  Mon Dec 16 16:33:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 16:33:35 GMT
Subject: RFR: 8346257: Problemlist jdp tests for macosx-aarch64
In-Reply-To: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
References: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
Message-ID: <GXX_yaGrtvFal_OPRXCqc1JNWW3Tf2PmXRZ4AT7o5uA=.977e92bf-2717-491a-bb6b-8627137e9d23@github.com>

On Mon, 16 Dec 2024 09:57:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Fairly frequent failures on macosx-aarch64.  For a while it was always on 15.0.1, but now also seen on "Mac OS X 12.7.1 (aarch64)", so this should be problemlisted for macosx-aarch64.
> 
> There are existing entries for aix, and the ProblemList file says it only wants one line per test. 
> 
> Trivial change tested in CI which shows that sun/management/jdp/JdpOffTest.java still runs on macosx-aarch64.
> 
> Tests failing:
> sun/management/jdp/JdpSpecificAddressTest.java
> sun/management/jdp/JdpDefaultsTest.java
> sun/management/jdp/JdpJmxRemoteDynamicPortTest.java

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22758#pullrequestreview-2506704353

From cjplummer at openjdk.org  Mon Dec 16 16:40:40 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 16:40:40 GMT
Subject: RFR: 8346261: Cleanup in JDP tests
In-Reply-To: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
References: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
Message-ID: <mRDRo1cXqREER8GlsglTJ9WiMfrQkD2xng-cxGJW66Y=.8a66fe93-26c4-454f-b3b5-5bf38d037d00@github.com>

On Mon, 16 Dec 2024 11:11:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple test update to fix some typos and formatting changes, seen while investigating and testing for JDK-8241865.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22761#pullrequestreview-2506724102

From mdoerr at openjdk.org  Mon Dec 16 16:45:48 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Dec 2024 16:45:48 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>
Message-ID: <qgeA2eXkaOqycu4ifjSfj1v2oMEAHah3Bqt-uEreotw=.a57be82b-c1d8-43f0-bab7-bbc6438e5c29@github.com>

On Mon, 16 Dec 2024 16:28:29 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> again what's the use case?

Assume a customer uses a tool like the async profiler and causes a JVM crash by doing that. A supporter looks at the hs_err file and wonders about what might have happened. Such a hint would be very helpful.

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546123339

From kevinw at openjdk.org  Mon Dec 16 17:05:42 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 17:05:42 GMT
Subject: RFR: 8346257: Problemlist jdp tests for macosx-aarch64
In-Reply-To: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
References: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
Message-ID: <cG2wXbHQegXtJ9m0t0W0655YnRx5eN5iiZ7gDcAOWVY=.cb8cfbb7-a963-4c06-8a5b-c5ff6286399c@github.com>

On Mon, 16 Dec 2024 09:57:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Fairly frequent failures on macosx-aarch64.  For a while it was always on 15.0.1, but now also seen on "Mac OS X 12.7.1 (aarch64)", so this should be problemlisted for macosx-aarch64.
> 
> There are existing entries for aix, and the ProblemList file says it only wants one line per test. 
> 
> Trivial change tested in CI which shows that sun/management/jdp/JdpOffTest.java still runs on macosx-aarch64.
> 
> Tests failing:
> sun/management/jdp/JdpSpecificAddressTest.java
> sun/management/jdp/JdpDefaultsTest.java
> sun/management/jdp/JdpJmxRemoteDynamicPortTest.java

Thanks Chris!

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

PR Comment: https://git.openjdk.org/jdk/pull/22758#issuecomment-2546163861

From kevinw at openjdk.org  Mon Dec 16 17:05:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 17:05:43 GMT
Subject: Integrated: 8346257: Problemlist jdp tests for macosx-aarch64
In-Reply-To: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
References: <D8SN9EP9Ff2fZiPEUxUzD08F1ppw9T4DMMnXumPwHAM=.ccac2104-4887-48ab-89e8-051bf7e89d28@github.com>
Message-ID: <LWVRa_ebUAFQnwSMMQMt9wktne3UYqPJAG6UfRhKX2U=.e6e8385c-148b-41b4-9a2e-2c34a42981fb@github.com>

On Mon, 16 Dec 2024 09:57:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Fairly frequent failures on macosx-aarch64.  For a while it was always on 15.0.1, but now also seen on "Mac OS X 12.7.1 (aarch64)", so this should be problemlisted for macosx-aarch64.
> 
> There are existing entries for aix, and the ProblemList file says it only wants one line per test. 
> 
> Trivial change tested in CI which shows that sun/management/jdp/JdpOffTest.java still runs on macosx-aarch64.
> 
> Tests failing:
> sun/management/jdp/JdpSpecificAddressTest.java
> sun/management/jdp/JdpDefaultsTest.java
> sun/management/jdp/JdpJmxRemoteDynamicPortTest.java

This pull request has now been integrated.

Changeset: 23708d01
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23708d01668e3c9154a73d8c84da4704457d43d6
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8346257: Problemlist jdp tests for macosx-aarch64

Reviewed-by: cjplummer

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

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

From kevinw at openjdk.org  Mon Dec 16 17:20:43 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 17:20:43 GMT
Subject: RFR: 8346261: Cleanup in JDP tests
In-Reply-To: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
References: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
Message-ID: <aRBwZXcrOYd50Gu1yDb-PJJFC9ML-TYJX8Cu4ESwF2U=.8ae76bdc-3e6b-467e-a30c-926e7b3ad0b9@github.com>

On Mon, 16 Dec 2024 11:11:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple test update to fix some typos and formatting changes, seen while investigating and testing for JDK-8241865.

Thanks again!

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

PR Comment: https://git.openjdk.org/jdk/pull/22761#issuecomment-2546199952

From kevinw at openjdk.org  Mon Dec 16 17:20:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 16 Dec 2024 17:20:44 GMT
Subject: Integrated: 8346261: Cleanup in JDP tests
In-Reply-To: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
References: <49OadIoWQUQf1OpjnCaWWa8vKU0iEOtNoVI2Nmm0RGU=.95c82dc7-7976-4f0d-8745-dddc39436c00@github.com>
Message-ID: <s0S1YdAQSdQY_6bP6UGlHczunxpRr1ImbYEhEzU9vx4=.4a9156fa-ea83-444b-9898-95e1f18b063c@github.com>

On Mon, 16 Dec 2024 11:11:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Simple test update to fix some typos and formatting changes, seen while investigating and testing for JDK-8241865.

This pull request has now been integrated.

Changeset: 57adf64a
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/57adf64ab4e50fd1739eb8ed14331d49f943b5e5
Stats:     37 lines in 10 files changed: 5 ins; 7 del; 25 mod

8346261: Cleanup in JDP tests

Reviewed-by: cjplummer

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

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

From cjplummer at openjdk.org  Mon Dec 16 17:27:38 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 17:27:38 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
Message-ID: <sCS6QmZYC7P_bMWzS7zocUmLOc1eBXCpE37lt2wpNZs=.d29a0038-bb11-4317-a2ca-53887da7f247@github.com>

On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
>> 
>> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
>> 
>> Testing:
>> 
>> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
>> - [x] tier1
>> - [x] tier2 svc
>> - [x] tier5 svc
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename run1() to test()

Looking for one more review. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2546219633

From cjplummer at openjdk.org  Mon Dec 16 17:29:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 17:29:35 GMT
Subject: RFR: 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: <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@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).

Are you going to add a test case?

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

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2546224806

From coleenp at openjdk.org  Mon Dec 16 17:50:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 17:50:51 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
Message-ID: <-PbL_IeJhucqF87KZMJhkbf0BEVPSXErqzMUndM357Y=.1b101482-89a0-46a8-9a44-491d2f2d79ac@github.com>

On Fri, 13 Dec 2024 21:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment about compute_modifiers().

Thanks Fred and David.  If I make further changes to modifiers, it'll be in a different RFE.

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

PR Comment: https://git.openjdk.org/jdk/pull/22618#issuecomment-2546263159

From fparain at openjdk.org  Mon Dec 16 17:50:51 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 16 Dec 2024 17:50:51 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
Message-ID: <4LHbAZl6-8ShuvFIo4XCcx49xopBP3vbFFlrLiXlrsA=.f625ce76-9d9a-4eb5-91f7-15697a50b66e@github.com>

On Fri, 13 Dec 2024 21:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment about compute_modifiers().

Marked as reviewed by fparain (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2506878474

From coleenp at openjdk.org  Mon Dec 16 17:50:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 17:50:52 GMT
Subject: Integrated: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <cez9DLLN6m2jyY5KfWL-yCuU_McVUfpDfrulLB6q6d8=.0264aaa3-e268-485f-8200-27bbe9613251@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

This pull request has now been integrated.

Changeset: d3359417
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3359417f3cb853b078041d07b8459b7b29a0a94
Stats:     39 lines in 8 files changed: 18 ins; 17 del; 4 mod

8345678: compute_modifiers should not be in create_mirror

Reviewed-by: fparain, dholmes

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

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

From larry.cable at oracle.com  Mon Dec 16 18:09:50 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Mon, 16 Dec 2024 10:09:50 -0800
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <qgeA2eXkaOqycu4ifjSfj1v2oMEAHah3Bqt-uEreotw=.a57be82b-c1d8-43f0-bab7-bbc6438e5c29@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>
 <qgeA2eXkaOqycu4ifjSfj1v2oMEAHah3Bqt-uEreotw=.a57be82b-c1d8-43f0-bab7-bbc6438e5c29@github.com>
Message-ID: <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>




On 12/16/24 8:45 AM, Martin Doerr wrote:
> On Mon, 16 Dec 2024 16:28:29 GMT, Laurence Cable <larry.cable at oracle.com> wrote:
>
>> again what's the use case?
> Assume a customer uses a tool like the async profiler and causes a JVM crash by doing that. A supporter looks at the hs_err file and wonders about what might have happened. Such a hint would be very helpful.

I was referring to the suggestion that there should be a jcmd to emit 
agent info ... I dont see that as useful
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546123339


From mbaesken at openjdk.org  Mon Dec 16 18:26:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 18:26:47 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
Message-ID: <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>

On Mon, 16 Dec 2024 18:11:29 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

>  jcmd to emit agent info 

Okay, then avoid adding it to jcmd;  for hserr adding the info is more important.

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546336030

From mbaesken at openjdk.org  Mon Dec 16 18:26:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 18:26:47 GMT
Subject: Integrated: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <jzFB8BGV3rgc8_1Pqxjwnht23E2l2t7K7YTLVdT0BRI=.a7700910-1aa1-4ec5-bb56-a84879b9e217@github.com>

On Thu, 12 Dec 2024 09:42:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should output more information about the JVMTI agents in the hserr file.

This pull request has now been integrated.

Changeset: c75b1d4b
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c75b1d4bf65d927e18b10ea6de263a331b78e13a
Stats:     40 lines in 4 files changed: 39 ins; 1 del; 0 mod

8346082: Output JVMTI agent information in hserr files

Reviewed-by: mdoerr, dholmes, stuefe

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

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

From stuefe at openjdk.org  Mon Dec 16 18:41:46 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 16 Dec 2024 18:41:46 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
 <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>
Message-ID: <h2dcwfW-tdcqyYhsB_a4vy6IBKv-5OSW65ooy3VBqkw=.0d0ea0ee-921e-4ce1-a38c-d513f61ca447@github.com>

On Mon, 16 Dec 2024 18:22:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > jcmd to emit agent info
> 
> Okay, then let's avoid adding it to jcmd; for hserr/hsinfo adding the info is more important.
> 
> My idea was that currently we can do 'data dump' and 'load agents' with jcmd
> 
> ```
> JVMTI.agent_load
> JVMTI.data_dump
> ```
> 
> So for completeness, when you offer loading agents, it might be useful to be able to _**show**_ the current agents with the same tool jcmd. But on the other hand you are probably correct that this new option might not be used a lot so it is maybe not worth the effort.

Since we already have VM.info jcmd, which after your patch already shows jvmti info, a separate command would be redundant, no?

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

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546367238

From vaivanov at openjdk.org  Mon Dec 16 19:18:44 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 16 Dec 2024 19:18:44 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <y3fTqfvJi8Yd9J0zhO19-CDX6CFSGjqhifF0Psc0N28=.42be9bbe-a060-4501-a4f8-72074536df9d@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

For the Xeon(R) 6972P scores for the specjvm::serial for current mainline looks as:
orig: 1T - 133.38 ops/m, 192T - 8950.13 ops/m
patched: 1T - 137.85 ops/m; 192T - 9745.03 ops/m

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

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2546435208

From duke at openjdk.org  Mon Dec 16 19:56:46 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 16 Dec 2024 19:56:46 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
Message-ID: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@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

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

Commit messages:
 - Fix concurrency issue. Add assertions. Update tests.
 - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"

Changes: https://git.openjdk.org/jdk/pull/22745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346123
  Stats: 102 lines in 19 files changed: 54 ins; 24 del; 24 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  Mon Dec 16 20:37:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 20:37:45 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags.
Message-ID: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>

Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

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

Commit messages:
 - 8346304: SA doesn't need a copy of getModifierFlags.

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

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

From sspitsyn at openjdk.org  Mon Dec 16 20:51:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 20:51:37 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM [v2]
In-Reply-To: <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
 <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
Message-ID: <mv2f6h6dL3L6OyRXEefZNeI137yG7y7ll3lVK5G4i7Y=.e0c52215-5c3b-445b-9594-c435ea02e945@github.com>

On Mon, 16 Dec 2024 16:06:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22746#pullrequestreview-2507333392

From sspitsyn at openjdk.org  Mon Dec 16 21:00:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:00:37 GMT
Subject: RFR: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest [v3]
In-Reply-To: <kRZUdAiblUOlC_xKUY84P8MxtwiM2rcdN23PlNC5qXA=.dd1012a2-4a23-471b-af71-33e49ac01c45@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
 <kRZUdAiblUOlC_xKUY84P8MxtwiM2rcdN23PlNC5qXA=.dd1012a2-4a23-471b-af71-33e49ac01c45@github.com>
Message-ID: <hpnSr1jvpu0k8Zw0V9W2mHCgOM0pxz7b5JazgSi9-vc=.f2cc914f-f61a-4af8-b33b-7cc50ed44eda@github.com>

On Fri, 13 Dec 2024 23:07:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
>> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
>> The fix adds handling of the errors to get information for analysis.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright update

This is good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22727#pullrequestreview-2507347039

From sspitsyn at openjdk.org  Mon Dec 16 21:05:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:05:38 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v4]
In-Reply-To: <vJA2HSjb4Na3xCEwuCLItgei35-zQSiTGhNhpzvydLw=.6957942f-94fa-43c5-a5a0-71d8bcef5323@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <vJA2HSjb4Na3xCEwuCLItgei35-zQSiTGhNhpzvydLw=.6957942f-94fa-43c5-a5a0-71d8bcef5323@github.com>
Message-ID: <0Qe7St-X1vrhMDh-CbV4GGqyFTKUtVh4YkCTFlnykQ8=.995eff19-1512-4456-90db-1274cd3dbbb5@github.com>

On Fri, 13 Dec 2024 21:29:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
>> 
>> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
>> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22223#pullrequestreview-2507355239

From sspitsyn at openjdk.org  Mon Dec 16 21:08:35 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:08:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags.
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <bwFL3Qhmkl5vSpGCJA_E5YmNkGlIu0ezxh9uVo13ZS8=.1577adcd-7193-4c64-b17c-2d99ec1fb31e@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Looks okay to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22772#pullrequestreview-2507360558

From sspitsyn at openjdk.org  Mon Dec 16 21:34:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:34:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <7kXOqKNvv9WRbSQfdbUBXqvFWx0dp2ZPEaRLPNtc31w=.b7b06c81-3f88-463f-a263-db0ace883eb3@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

Looks good to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22173#pullrequestreview-2507399979

From kbarrett at openjdk.org  Mon Dec 16 22:28:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Dec 2024 22:28:35 GMT
Subject: RFR: 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: <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@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

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/memTracker.hpp line 281:

> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
> 280:   // Performs no action during VM init.
> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {

Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
the current thread, like all the other locker variants.

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

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2507464880
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887650768

From coleenp at openjdk.org  Mon Dec 16 22:43:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 22:43:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Do you agree it's trivial?  GHA almost complete/passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547015672

From sspitsyn at openjdk.org  Mon Dec 16 22:54:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 22:54:34 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases
In-Reply-To: <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@github.com>
Message-ID: <FgUm5T0lyw5haGPG94P6xpUWek0vOMSVyMNoqxS2DG0=.99e890ff-6f84-469c-80d0-d646bbfd0685@github.com>

On Mon, 16 Dec 2024 17:27:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Are you going to add a test case?

You are right. While relying on the JDWP level of testing it is better to add a JVMTI test case for this fix as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2547039257

From sspitsyn at openjdk.org  Mon Dec 16 23:25:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 23:25:49 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
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: <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@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:

  added extra check to post_method_exit_inner before clear_frame_pop to avoid assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/1080d282..b04f078f

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

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 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  Mon Dec 16 23:30:35 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 23:30:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
 <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>
Message-ID: <iNTqcD6za043HtI7OIFMNa2Ze-9XkbajlBU4yUxcZYc=.e49809d6-beda-4c0e-937a-35e46f717e8e@github.com>

On Mon, 16 Dec 2024 22:41:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Do you agree it's trivial?

I'm not sure about it.

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

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547114241

From coleenp at openjdk.org  Mon Dec 16 23:30:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 23:30:36 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <f636GWo9Doff3fk7e6Hxdqxr06r_RhZwalwvcTMsI84=.89c989b5-72a8-436a-9bf0-d61aa1b748df@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

ok, I'll wait and see what @plummercj says.

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

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547117726

From cjplummer at openjdk.org  Mon Dec 16 23:59:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 23:59:36 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <jOQq6p6fJQ8jZRtrNJOeE2Z_OZQijleQVyFaipOtcuI=.b53de9df-1cd5-48f8-b583-23b651ce0f24@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22772#pullrequestreview-2507583428

From dholmes at openjdk.org  Tue Dec 17 00:25:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 00:25:35 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
Message-ID: <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>

On Mon, 16 Dec 2024 22:15:45 GMT, Kim Barrett <kbarrett 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
>
> src/hotspot/share/nmt/memTracker.hpp line 281:
> 
>> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
>> 280:   // Performs no action during VM init.
>> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {
> 
> Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
> Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
> the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
> the current thread, like all the other locker variants.

You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887738017

From dholmes at openjdk.org  Tue Dec 17 01:58:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 01:58:36 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM [v2]
In-Reply-To: <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
 <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
Message-ID: <Vz0vO2Sy6d4JUfUBGWY6CiwNb6SnMRUwaGx1etiuYIE=.0a8298a3-31cf-4eda-b942-150a27c1787f@github.com>

On Mon, 16 Dec 2024 16:06:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22746#pullrequestreview-2507694949

From dholmes at openjdk.org  Tue Dec 17 02:02:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 02:02:41 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
Message-ID: <gDSr29rKWsmJLNQ0j5bDYq-Y-G3n1OLnFn4keQmG0sE=.8783a810-eec0-4c04-9ca9-f6a99610bb4c@github.com>

On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
>> 
>> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
>> 
>> Testing:
>> 
>> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
>> - [x] tier1
>> - [x] tier2 svc
>> - [x] tier5 svc
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename run1() to test()

Hitting approve, but the launcher change seems unrelated to the issue at hand.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22620#pullrequestreview-2507698636

From dholmes at openjdk.org  Tue Dec 17 02:02:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 02:02:42 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
Message-ID: <PbxXS8ZiVaQ0iElTBgEUBRTJVvBMNfTGw-IagN1Futk=.65b009c6-f71a-4531-838d-7e0e5c4abd42@github.com>

On Sat, 7 Dec 2024 07:33:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename run1() to test()
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 142:
> 
>> 140:             /* Some jdb tests need java.library.path setup for native libraries. */
>> 141:             String libpath = System.getProperty("java.library.path");
>> 142:             args.add("-R-Djava.library.path=" + libpath);
> 
> Good, I wasn't sure how this would inherit.

This seems like an unrelated change. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1887796036

From cjplummer at openjdk.org  Tue Dec 17 02:27:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 02:27:37 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <PbxXS8ZiVaQ0iElTBgEUBRTJVvBMNfTGw-IagN1Futk=.65b009c6-f71a-4531-838d-7e0e5c4abd42@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
 <PbxXS8ZiVaQ0iElTBgEUBRTJVvBMNfTGw-IagN1Futk=.65b009c6-f71a-4531-838d-7e0e5c4abd42@github.com>
Message-ID: <pTTCBlZtsug4RGS22NM-iNv4Ichv01WEnyVv6GHbDx0=.23421b8c-c68f-4011-94af-7681cf55a2d5@github.com>

On Tue, 17 Dec 2024 01:59:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 142:
>> 
>>> 140:             /* Some jdb tests need java.library.path setup for native libraries. */
>>> 141:             String libpath = System.getProperty("java.library.path");
>>> 142:             args.add("-R-Djava.library.path=" + libpath);
>> 
>> Good, I wasn't sure how this would inherit.
>
> This seems like an unrelated change. ???

jdk.test.lib.thread.VThreadPinner has a native library that must be loaded.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1887810706

From cjplummer at openjdk.org  Tue Dec 17 03:42:45 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 03:42:45 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
Message-ID: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>

On Mon, 16 Dec 2024 23:25:49 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:
> 
>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert

All my debugger testing is passing now. A few comments inline.

src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:

> 578:   // notify debugger of an exception catch
> 579:   // (this is good for exceptions caught in native methods as well)
> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {

This doesn't seem like it is related to ClearAllFramePops.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1365:

> 1363:   if (ets->is_frame_pop(frame_number)) {
> 1364:     return JVMTI_ERROR_DUPLICATE;
> 1365:   }

It seems that this change is unrelated to ClearAllFramePops and perhaps deserves it's own CR, especially since it is a behavior change.

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:

> 261: #ifdef ASSERT
> 262:   Thread *current = Thread::current();
> 263: #endif

I think you can just get rid of these lines and inline the Thread.current() call below.

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 505:

> 503:   err = jvmti->NotifyFramePop(thread, 0);
> 504:   check_jvmti_status(jni, err, "VirtualThreadUnmount: error in JVMTI NotifyFramePop");
> 505: 

I assume this is needed as the result of your fix to return DUPLICATE for NotifyFramePop. Do we know that it always returns DUPLICATE for this particular call site?

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

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2507765531
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887841702
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887845533
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887849471
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887851575

From kbarrett at openjdk.org  Tue Dec 17 04:03:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 04:03:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
Message-ID: <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>

On Tue, 17 Dec 2024 00:23:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/nmt/memTracker.hpp line 281:
>> 
>>> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
>>> 280:   // Performs no action during VM init.
>>> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {
>> 
>> Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
>> Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
>> the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
>> the current thread, like all the other locker variants.
>
> You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.

CML could perhaps be used has-a (though that might be messy), but should not
be used is-a.  One of the basic rules for base classes is to have either a
public virtual destructor (don't do that here) or a non-public non-virtual
destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
designed to be a base class.  CML doesn't - it was not designed to be a base
class.  (There is a common (though not universal) opinion that classes should
either be base or concrete classes, not both.) I know we violate this rule all
over the place; that doesn't mean we should do so here.

But really, there's no benefit to using CML here. Deriving from
MutexLockerImpl is about the same number of characters, and seems clearer to
me because it's more direct.


class NmtVirtualMemoryLocker : public MutexLockerImpl {
public:
  NmtVirtualMemoryLocker()
    : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
                      Mutex::_no_safepoint_check_flag)
  {}
}


Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
(I remember a discussion a long time ago about whether StackObj should be
noncopyable, which foundered on a combination of some significant number of
existing uses that violated that restriction, along with disagreement about
the meaning of deriving from StackObj.  So we're not getting noncopyable from
there.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887863262

From dholmes at openjdk.org  Tue Dec 17 04:24:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:24:37 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual. [v2]
In-Reply-To: <pTTCBlZtsug4RGS22NM-iNv4Ichv01WEnyVv6GHbDx0=.23421b8c-c68f-4011-94af-7681cf55a2d5@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <4Szx0An-PQ9VcTr0d0ML8D6lHlbOcP5lUrzq81AeeFA=.ec161337-9cd6-459f-80f0-57145ae0af04@github.com>
 <PbxXS8ZiVaQ0iElTBgEUBRTJVvBMNfTGw-IagN1Futk=.65b009c6-f71a-4531-838d-7e0e5c4abd42@github.com>
 <pTTCBlZtsug4RGS22NM-iNv4Ichv01WEnyVv6GHbDx0=.23421b8c-c68f-4011-94af-7681cf55a2d5@github.com>
Message-ID: <3zQMtYlIgJOjwQk_rGiiTOWoI4qVZKUummGrBb0Xlc0=.3f79ade9-5a34-4bef-989e-c5b1c5629811@github.com>

On Tue, 17 Dec 2024 02:25:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This seems like an unrelated change. ???
>
> jdk.test.lib.thread.VThreadPinner has a native library that must be loaded.

Ah I see. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1887874661

From dholmes at openjdk.org  Tue Dec 17 07:00:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 07:00:48 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
Message-ID: <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>

On Tue, 17 Dec 2024 04:01:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.
>
> CML could perhaps be used has-a (though that might be messy), but should not
> be used is-a.  One of the basic rules for base classes is to have either a
> public virtual destructor (don't do that here) or a non-public non-virtual
> destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
> designed to be a base class.  CML doesn't - it was not designed to be a base
> class.  (There is a common (though not universal) opinion that classes should
> either be base or concrete classes, not both.) I know we violate this rule all
> over the place; that doesn't mean we should do so here.
> 
> But really, there's no benefit to using CML here. Deriving from
> MutexLockerImpl is about the same number of characters, and seems clearer to
> me because it's more direct.
> 
> 
> class NmtVirtualMemoryLocker : public MutexLockerImpl {
> public:
>   NmtVirtualMemoryLocker()
>     : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
>                       Mutex::_no_safepoint_check_flag)
>   {}
> }
> 
> 
> Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
> (I remember a discussion a long time ago about whether StackObj should be
> noncopyable, which foundered on a combination of some significant number of
> existing uses that violated that restriction, along with disagreement about
> the meaning of deriving from StackObj.  So we're not getting noncopyable from
> there.)

`MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887992575

From coleenp at openjdk.org  Tue Dec 17 12:41:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:41:39 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <45Ov_nZh2_DHP2y4InccwhTH3oOmiDoN5UBPCUS2gBo=.514207f4-c3c2-4346-b606-e3038079175c@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Thanks Chris and Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2548346300

From coleenp at openjdk.org  Tue Dec 17 12:41:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:41:39 GMT
Subject: Integrated: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <vOkjcmn86Hl2Iy27w-bb9g-r79HcovZ230-W7_foT_0=.ec44c4f5-3c83-493b-9e49-bde7a7e49d25@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

This pull request has now been integrated.

Changeset: baeb3d9a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baeb3d9ab889cddcce1c00728098ae5a5120eeb2
Stats:     78 lines in 5 files changed: 0 ins; 76 del; 2 mod

8346304: SA doesn't need a copy of getModifierFlags

Reviewed-by: sspitsyn, cjplummer

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

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

From coleenp at openjdk.org  Tue Dec 17 13:03:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 13:03:41 GMT
Subject: RFR: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM [v2]
In-Reply-To: <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
 <tW1gzXdMATGFuvwpD3UUie6AO8bNqXkqlgGDll4Tqi4=.7296769f-8286-410f-8a67-c1a5929a0f8a@github.com>
Message-ID: <Wl2Y6tM4MWdKgdHIYmEQyIplPObJgMtwyM6L8enBjAc=.afe08fd8-7b0f-4ffa-83ad-e93c30111e0c@github.com>

On Mon, 16 Dec 2024 16:06:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Thank you for reviewing, David and Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/22746#issuecomment-2548396619

From coleenp at openjdk.org  Tue Dec 17 13:03:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 13:03:42 GMT
Subject: Integrated: 8337016:
 serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace
 OOM
In-Reply-To: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
References: <Q05kJUEmliH88uPZB5eHUbIYCl5yke-mXezYOVAAl3M=.414da2be-8546-4dca-8b6c-1b5d86958a4b@github.com>
Message-ID: <sCbqcdDkvHtHu9Vx3TvTvnX4N5KYEpm6xYRXOoZg4bc=.d140171f-9a84-458d-9696-c1c0bcecbb44@github.com>

On Fri, 13 Dec 2024 22:25:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This increases MaxMetaspaceSize for this test so that it can be run with CDS turned off.  This change is upstreamed from the valhalla repo from when it didn't have CDS on.  The test still finds a metaspace leak with this larger MaxMetaspaceSize.

This pull request has now been integrated.

Changeset: fbd76ca8
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fbd76ca8edd756ff2ebbc9f6477cc1a827df67b0
Stats:     16 lines in 1 file changed: 0 ins; 15 del; 1 mod

8337016: serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java gets Metaspace OOM

Reviewed-by: dholmes, sspitsyn

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

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

From ihse at openjdk.org  Tue Dec 17 13:20:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 17 Dec 2024 13:20:11 GMT
Subject: RFR: 8346383: Cannot use DllMain in libdt_socket for static builds
Message-ID: <hny6Fwwssk35QtToCt69dhzhADaZM6xa4a9Sqi3E7zQ=.e3d16e12-c4a4-4e5a-a59d-fe399fb9da92@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. "

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

Commit messages:
 - 8346383: Cannot use DllMain in libdt_socket for static builds

Changes: https://git.openjdk.org/jdk/pull/22789/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346383
  Stats: 41 lines in 4 files changed: 19 ins; 13 del; 9 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 ihse at openjdk.org  Tue Dec 17 13:20:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 17 Dec 2024 13:20:11 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: <2hwhy_VyYU5cepnkl02iRcp0BTRuqLbbDFIo0Mh29gw=.5456f242-0886-4e38-a9e7-dc948dd8c36b@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. "

I'm not sure what tests to run for this change, apart from tier1. I am open to suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/22789#issuecomment-2548174056

From duke at openjdk.org  Tue Dec 17 13:48:37 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 13:48:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
 <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
Message-ID: <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>

On Tue, 17 Dec 2024 06:57:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> CML could perhaps be used has-a (though that might be messy), but should not
>> be used is-a.  One of the basic rules for base classes is to have either a
>> public virtual destructor (don't do that here) or a non-public non-virtual
>> destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
>> designed to be a base class.  CML doesn't - it was not designed to be a base
>> class.  (There is a common (though not universal) opinion that classes should
>> either be base or concrete classes, not both.) I know we violate this rule all
>> over the place; that doesn't mean we should do so here.
>> 
>> But really, there's no benefit to using CML here. Deriving from
>> MutexLockerImpl is about the same number of characters, and seems clearer to
>> me because it's more direct.
>> 
>> 
>> class NmtVirtualMemoryLocker : public MutexLockerImpl {
>> public:
>>   NmtVirtualMemoryLocker()
>>     : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
>>                       Mutex::_no_safepoint_check_flag)
>>   {}
>> }
>> 
>> 
>> Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
>> (I remember a discussion a long time ago about whether StackObj should be
>> noncopyable, which foundered on a combination of some significant number of
>> existing uses that violated that restriction, along with disagreement about
>> the meaning of deriving from StackObj.  So we're not getting noncopyable from
>> there.)
>
> `MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.

Ok I see. I will stop using `ConditionalMutexLocker` as a base class. Instead, I'll just get rid of `NmtVirtualMemoryLocker` and use `ConditionalMutexLocker` directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1888546778

From sgehwolf at openjdk.org  Tue Dec 17 15:05:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 17 Dec 2024 15:05:22 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v14]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <lsCSye-w4Lbx8oCeJzHLkwteOt6BksvMTOy4v7UlUog=.5ef038ba-3574-4a2f-b12c-f969902befa0@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 40 commits:

 - 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
 - Improve systemd slice test for non-root on cg v2
 - ... and 30 more: https://git.openjdk.org/jdk/compare/ff85865b...ceffcfc6

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

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=13
  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 sgehwolf at openjdk.org  Tue Dec 17 15:07:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 17 Dec 2024 15:07:42 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v13]
In-Reply-To: <iQlyCOZvt_8gceL8zoCP0H54cnJfbvpMetxyqD2RIOs=.ad4e245b-fd17-444d-abaf-3a449b5590a7@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <iQlyCOZvt_8gceL8zoCP0H54cnJfbvpMetxyqD2RIOs=.ad4e245b-fd17-444d-abaf-3a449b5590a7@github.com>
Message-ID: <F5f5zyWNSLXE9OdSBh3i40PeHFnp-sswyu7Xt56u-U4=.a97fea36-dd27-4b2a-bb05-8bd4034ec447@github.com>

On Tue, 19 Nov 2024 13:37:25 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 38 commits:
> 
>  - 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
>  - Improve systemd slice test for non-root on cg v2
>  - Fix unit tests
>  - Add JVM_HostActiveProcessorCount using JVM api
>  - ... and 28 more: https://git.openjdk.org/jdk/compare/23597361...b56fc7b7

Ping? Still looking for a review of this, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2548694574

From duke at openjdk.org  Tue Dec 17 15:30:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 15:30:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v2]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <BOOlQ28V2IxdNoDWMf_GuNi7b_K5gpjGwqCIixEofuY=.659c49d2-f51d-4eb3-835d-d99c355752a0@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 ConditionalMutexLocker directly

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/e817cf1f..c169ff80

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

  Stats: 21 lines in 9 files changed: 0 ins; 0 del; 21 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 Dec 17 15:46:01 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 15:46:01 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@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:

  updates tests and remove old class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/c169ff80..1d07d95a

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

  Stats: 14 lines in 2 files changed: 1 ins; 9 del; 4 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 vaivanov at openjdk.org  Tue Dec 17 16:14:40 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 17 Dec 2024 16:14:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <eOjx1HBvll6LUF5HsYb_IA5S06xxXRWyOmcSPeoxn2o=.1428f6c0-7352-4262-9fc4-b901e7d3e529@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2548906472

From duke at openjdk.org  Tue Dec 17 16:14:40 2024
From: duke at openjdk.org (duke)
Date: Tue, 17 Dec 2024 16:14:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <R3CmDBTcgtgqykxhszT7urbWfXGh-u2A2A0l5jqfp7Q=.b9348807-2624-4bcd-82a0-6f9c81a7fae7@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

@IvaVladimir 
Your change (at version ba234c592b976e8a3a8f1c1c2c66d9699c4ec265) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2548907410

From vaivanov at openjdk.org  Tue Dec 17 17:03:42 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 17 Dec 2024 17:03:42 GMT
Subject: Integrated: 8341481: [perf] vframeStreamCommon constructor may be
 optimized
In-Reply-To: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
Message-ID: <gXL6nsmjOPHe5TbJ1ujvorNh2N8cDQFbXl0g2YYq8Yc=.662e9ef7-1b99-4e42-ad37-2aa6347279ac@github.com>

On Sat, 16 Nov 2024 00:20:10 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.

This pull request has now been integrated.

Changeset: 4f44cf6b
Author:    Vladimir Ivanov <vaivanov at openjdk.org>
Committer: Derek White <drwhite at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f44cf6bf2423a57a841be817f348e3b1e88f0eb
Stats:     31 lines in 5 files changed: 11 ins; 1 del; 19 mod

8341481: [perf] vframeStreamCommon constructor may be optimized

Reviewed-by: sspitsyn

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

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

From sspitsyn at openjdk.org  Tue Dec 17 17:35:44 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:35:44 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <xYxm6MMDagLAKEg-e_cpEI-G3yq15D_6N95qi8qlzsM=.1f77524c-eb91-431f-a7d1-7308f50d2abd@github.com>

On Tue, 17 Dec 2024 03:27:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1365:
> 
>> 1363:   if (ets->is_frame_pop(frame_number)) {
>> 1364:     return JVMTI_ERROR_DUPLICATE;
>> 1365:   }
> 
> It seems that this change is unrelated to ClearAllFramePops and perhaps deserves it's own CR, especially since it is a behavior change.

Okay. Removed the `JVMTI_ERROR_DUPLICATE` related changes. Will fix it separately including the CSR.

> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:
> 
>> 261: #ifdef ASSERT
>> 262:   Thread *current = Thread::current();
>> 263: #endif
> 
> I think you can just get rid of these lines and inline the Thread.current() call below.

Okay, fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 505:
> 
>> 503:   err = jvmti->NotifyFramePop(thread, 0);
>> 504:   check_jvmti_status(jni, err, "VirtualThreadUnmount: error in JVMTI NotifyFramePop");
>> 505: 
> 
> I assume this is needed as the result of your fix to return DUPLICATE for NotifyFramePop. Do we know that it always returns DUPLICATE for this particular call site?

Yes, it is related to the DUPLICATE change.
The test calls JVMTI `NotifyFramePop` in the `VirtualThreadMount`/`VirtualThreadUnmount` event handlers.
One of them is a dup for sure and not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888942395
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888940655
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888939839

From sspitsyn at openjdk.org  Tue Dec 17 17:38:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:38:39 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>

On Tue, 17 Dec 2024 03:20:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:
> 
>> 578:   // notify debugger of an exception catch
>> 579:   // (this is good for exceptions caught in native methods as well)
>> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {
> 
> This doesn't seem like it is related to ClearAllFramePops.

Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888946592

From sspitsyn at openjdk.org  Tue Dec 17 17:49:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:49:14 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v3]
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: <CBHcijvQXSeEw2V2123sC_VgX9I6ng0hcZ90MdzYM5s=.e6f53453-1491-4fff-8480-1ea615ea9e5a@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:

  review: removed DUPLICATE related changes; a minor tweak for ASSERT line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/b04f078f..0e4ddcc1

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

  Stats: 15 lines in 4 files changed: 3 ins; 10 del; 2 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 Dec 17 17:49:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:49:14 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <gu9agh3DzqgKju97KTUM48V2JrHqXawCpkNpXK9yLPk=.ac946420-0141-46d8-97ac-5cd5962e9cc9@github.com>

On Tue, 17 Dec 2024 03:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> All my debugger testing is passing now. A few comments inline.

Thank you for testing my update in the debugging environment!

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

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2549152190

From amenkov at openjdk.org  Tue Dec 17 18:52:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 17 Dec 2024 18:52:42 GMT
Subject: RFR: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux [v4]
In-Reply-To: <vJA2HSjb4Na3xCEwuCLItgei35-zQSiTGhNhpzvydLw=.6957942f-94fa-43c5-a5a0-71d8bcef5323@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
 <vJA2HSjb4Na3xCEwuCLItgei35-zQSiTGhNhpzvydLw=.6957942f-94fa-43c5-a5a0-71d8bcef5323@github.com>
Message-ID: <ZixNAxAhXCMYTxpGgddzY0NIDsMs61UzyShLdIEb9LU=.5651b7a5-42f1-4312-980d-34bd2e9dc713@github.com>

On Fri, 13 Dec 2024 21:29:14 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
>> 
>> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
>> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Kevin, Serguei, thank you for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/22223#issuecomment-2549324375

From amenkov at openjdk.org  Tue Dec 17 18:52:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 17 Dec 2024 18:52:43 GMT
Subject: Integrated: 8342995: Enhance Attach API to support arbitrary length
 arguments - Linux
In-Reply-To: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
References: <qK5JSyPBMXci_WfZ3MAs7ADMkxe5jJY3H_-b2yhQDPo=.233cb496-d4fa-46cb-8eca-b47c37e6c181@github.com>
Message-ID: <NEeevw9vmQ35T9uUHxkwcE3WXfx9ZvRmJ7pq7pwmguY=.8c80ceed-ac89-4dbd-aaa1-0513aef02a29@github.com>

On Tue, 19 Nov 2024 00:04:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782)
> 
> Testing: tier1,tier2,tier3,tier4,hs-tier5-svc
> manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8.

This pull request has now been integrated.

Changeset: dc71e8ca
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc71e8cae95dfc6e4b2afdf8e8a255d9ffe5cdfa
Stats:     326 lines in 5 files changed: 98 ins; 193 del; 35 mod

8342995: Enhance Attach API to support arbitrary length arguments - Linux

Reviewed-by: sspitsyn, kevinw

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

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

From cjplummer at openjdk.org  Tue Dec 17 19:09:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 19:09:00 GMT
Subject: RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails
 with JTREG_TEST_THREAD_FACTORY=Virtual [v2]
In-Reply-To: <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
 <p-A4Y_IKgNr01qiDKdWNJC36OJJkS9F-8vM2NIpER4Y=.9febaaab-6306-4bb4-a7ac-e35e3aa0cd43@github.com>
Message-ID: <3dCUG6x8CUV4mIvHjwSfNk7WuwLO0-h9wS-aLfyMCmc=.317583e4-e96c-4537-8f55-32998a73a7e9@github.com>

On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
>> 
>> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
>> 
>> Testing:
>> 
>> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
>> - [x] tier1
>> - [x] tier2 svc
>> - [x] tier5 svc
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename run1() to test()

Thanks David and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/22620#issuecomment-2549373286

From cjplummer at openjdk.org  Tue Dec 17 19:09:00 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 19:09:00 GMT
Subject: Integrated: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java
 fails with JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
References: <XDCLuZseJ7W-PSQ43Be-cbv3KhujmBkamc1vOZiI2co=.ea774c8c-b139-45b5-8775-ce6695a6c022@github.com>
Message-ID: <x4vwkjLJRc0gk7MtFoBvzNsE6WzF1EN0ngZtfc5oZZE=.db18bd10-01b2-4129-855d-b0b6f62886df@github.com>

On Fri, 6 Dec 2024 22:28:29 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This test fails after [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a thread expecting it to be mounted. Before [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) it would be mounted because it was blocked on a syncrhonized, which resulted in the thread being pinned. After [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) this is no longer the case and the virtual thread has unmounted. This causes JVMTI StopThread to fail with JVMTI_ERROR_OPAQUE_FRAME because it only supports mounted virtual threads.
> 
> Fixed by using the VThreadPinner class to make sure the virtual threads remains pinned, and therefore mounted.
> 
> Testing:
> 
> - [x] Ran jdb tests locally in both virtual thread mode and platform thread mode.
> - [x] tier1
> - [x] tier2 svc
> - [x] tier5 svc

This pull request has now been integrated.

Changeset: 414eb6bb
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/414eb6bb83d092fbcd87d5ab72519b6eb109837f
Stats:     26 lines in 3 files changed: 15 ins; 9 del; 2 mod

8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with JTREG_TEST_THREAD_FACTORY=Virtual

Reviewed-by: sspitsyn, dholmes

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

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

From duke at openjdk.org  Tue Dec 17 19:42:36 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 19:42:36 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
Message-ID: <6dxe83dysekshNnBGeuYdGrsHdGIg4rayXM4van3KD8=.9e9f027a-7ec1-48d1-b6c0-cae7499a6d4c@github.com>

On Tue, 17 Dec 2024 15:46:01 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:
> 
>   updates tests and remove old class

The GHA test `windows-x64 / test (hs/tier1 gc)` is failing with: 

#  Internal Error (d:\a\jdk\jdk\src\hotspot\share\gc\shenandoah\shenandoahGeneration.cpp:1029), pid=2620, tid=4892
#  assert(ShenandoahHeap::heap()->is_full_gc_in_progress() || (_affiliated_region_count * ShenandoahHeapRegion::region_size_bytes() <= _max_capacity)) failed: Cannot use more than capacity

I don't think this is related to the changes in this PR. The same problem seems to have been reported a week ago here: [JDK-8345895](https://bugs.openjdk.org/browse/JDK-8345895)

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

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

From sspitsyn at openjdk.org  Tue Dec 17 21:05:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 21:05:46 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
Message-ID: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@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 request a breakpoint 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

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

Commit messages:
 - 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

Changes: https://git.openjdk.org/jdk/pull/22798/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346460
  Stats: 11 lines in 3 files changed: 7 ins; 3 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 amenkov at openjdk.org  Tue Dec 17 21:07:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 17 Dec 2024 21:07:39 GMT
Subject: Integrated: 8346151: Add transformer error logging to
 VerifyLocalVariableTableOnRetransformTest
In-Reply-To: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
References: <c8tSiqR6GjuVdYkr9ZprDal8FmDrG9IfFdFbVVUBWlE=.0538c2c6-61dd-4cb8-a7cf-6f8d23b61e79@github.com>
Message-ID: <vOKVeKlRb8Y9cu1g9RhUYg3FrOESRuJYqXTN7-OQpmg=.88a57639-f9d9-4bb6-8ec8-8b2b249fa864@github.com>

On Fri, 13 Dec 2024 02:21:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> In some circumstances ClassFileTransformer.transform can get ClassCircularityError or LinkageError concatenating strings (see JDK-8264667, JDK-8262002).
> VerifyLocalVariableTableOnRetransformTest fails sometimes on Oracle CI.
> The fix adds handling of the errors to get information for analysis.

This pull request has now been integrated.

Changeset: c0f0b8e5
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c0f0b8e5f4d83ae7dd7e67930c19134855e5e97b
Stats:     21 lines in 1 file changed: 15 ins; 0 del; 6 mod

8346151: Add transformer error logging to VerifyLocalVariableTableOnRetransformTest

Reviewed-by: cjplummer, sspitsyn

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

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

From coleenp at openjdk.org  Tue Dec 17 21:28:47 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 21:28:47 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
Message-ID: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@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.

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

Commit messages:
 - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
 - 8339113: AccessFlags can be u2 in metadata

Changes: https://git.openjdk.org/jdk/pull/22246/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339113
  Stats: 167 lines in 41 files changed: 16 ins; 40 del; 111 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 cjplummer at openjdk.org  Tue Dec 17 21:40:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 21:40:36 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
 <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
Message-ID: <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>

On Tue, 17 Dec 2024 17:35:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:
>> 
>>> 578:   // notify debugger of an exception catch
>>> 579:   // (this is good for exceptions caught in native methods as well)
>>> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {
>> 
>> This doesn't seem like it is related to ClearAllFramePops.
>
> Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.

So this is a long standing bug hidden by the fact that if `can_post_frame_pop()` is true, then so is `can_post_on_exceptions()`:


  JvmtiExport::set_can_post_on_exceptions(
    avail.can_generate_exception_events ||
    avail.can_generate_frame_pop_events ||
    avail.can_generate_method_exit_events);

  JvmtiExport::set_can_post_frame_pop(avail.can_generate_frame_pop_events);


Or you could argue that the existing code is correct because it already captures `can_post_frame_pop()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1889259920

From cjplummer at openjdk.org  Tue Dec 17 21:44:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 21:44:36 GMT
Subject: RFR: 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: <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@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

src/hotspot/share/prims/jvmti.xml line 3088:

> 3086:         </error>
> 3087:         <error id="JVMTI_ERROR_DUPLICATE">
> 3088:           There is already frame pop event request at the specified depth.

Suggestion:

          There is already a frame pop event request at the specified depth.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1889263242

From sspitsyn at openjdk.org  Wed Dec 18 00:22:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 00:22:11 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v4]
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: <9tTRNfROib49s9phM63-6n0itRfte7nAn6Q1mwSXOM4=.b1817c38-4c25-4cfe-b85f-743b3352e970@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:

  review: add a unit test covering JVMTI ClearAllFramePops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/0e4ddcc1..156c1580

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

  Stats: 261 lines in 2 files changed: 261 ins; 0 del; 0 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  Wed Dec 18 03:12:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:12:14 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@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:

  review: minor tweak in jvmti.xml update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/57aa3bdb..4106c10a

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

  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  Wed Dec 18 03:28:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:28:30 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
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: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@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:

  review: removed unneeded check for JvmtiExport::can_post_frame_pop()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/156c1580..850cafbd

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Wed Dec 18 03:28:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:28:31 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
 <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
 <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>
Message-ID: <BT2nbOFXdsq1Y62-odoZIG1oGz9KGU09VcrFCDjbchw=.ed98967f-0d11-4315-9c2f-a2a9c4f33428@github.com>

On Tue, 17 Dec 2024 21:38:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.
>
> So this is a long standing bug hidden by the fact that if `can_post_frame_pop()` is true, then so is `can_post_on_exceptions()`:
> 
> 
>   JvmtiExport::set_can_post_on_exceptions(
>     avail.can_generate_exception_events ||
>     avail.can_generate_frame_pop_events ||
>     avail.can_generate_method_exit_events);
> 
>   JvmtiExport::set_can_post_frame_pop(avail.can_generate_frame_pop_events);
> 
> 
> Or you could argue that the existing code is correct because it already captures `can_post_frame_pop()`.

Good check, thanks! Rolled back this change. I remember that I've added this because some of the tests was failing. Most likely, I had made a wrong conclusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1889553986

From dholmes at openjdk.org  Wed Dec 18 04:39:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 04:39:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
Message-ID: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>

On Tue, 17 Dec 2024 15:46:01 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:
> 
>   updates tests and remove old class

The direct use of CML is functionally correct but requires leaking knowledge to all the use-sites that should not need to know about the actual condition for locking. This really needs to be encapsulated which means we need to be able to subclass CML.

@kbarrett what is needed to make `ConditionalMutexLocker` subclassable?

src/hotspot/os/windows/os_windows.cpp line 3624:

> 3622: #ifdef ASSERT
> 3623:       fileStream fs(stdout);
> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);

Why was this change made? tty could be stdout or stderr depending on VM flag settings.

src/hotspot/share/runtime/threads.cpp line 530:

> 528: 
> 529:   // Once mutexes are ready, we can use NMT locks.
> 530:   MemTracker::set_done_bootstrap();

This should be done after the main thread has attached and set the current thread, otherwise if we hit any NMT code that needs the lock it would crash trying to acquire it.

src/hotspot/share/utilities/vmError.cpp line 720:

> 718: 
> 719:   BEGIN
> 720:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr && NmtVirtualMemory_lock->owned_by_self()) {

Suggestion:

  if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2510765294
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889595113
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889598981
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889600501

From syan at openjdk.org  Wed Dec 18 07:10:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Dec 2024 07:10:45 GMT
Subject: [jdk24] RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java
 fails with JTREG_TEST_THREAD_FACTORY=Virtual
Message-ID: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>

Hi all,

This pull request contains a backport of commit [414eb6bb](https://github.com/openjdk/jdk/commit/414eb6bb83d092fbcd87d5ab72519b6eb109837f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Chris Plummer on 17 Dec 2024 and was reviewed by Serguei Spitsyn and David Holmes.

Thanks!

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

Commit messages:
 - Backport 414eb6bb83d092fbcd87d5ab72519b6eb109837f

Changes: https://git.openjdk.org/jdk/pull/22805/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338714
  Stats: 26 lines in 3 files changed: 15 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22805.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22805/head:pull/22805

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

From duke at openjdk.org  Wed Dec 18 14:40:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 14:40:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v4]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <KSb49qWHhhsNjolnVd0wVSlPCg0fynvzP5QE-QcA8Os=.10b160cb-d32f-4d48-a986-c7c2d21bd5cc@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/utilities/vmError.cpp
  
  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/1d07d95a..a51cdc61

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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 duke at openjdk.org  Wed Dec 18 14:40:55 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 14:40:55 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>

On Wed, 18 Dec 2024 04:24:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates tests and remove old class
>
> src/hotspot/os/windows/os_windows.cpp line 3624:
> 
>> 3622: #ifdef ASSERT
>> 3623:       fileStream fs(stdout);
>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
> 
> Why was this change made? tty could be stdout or stderr depending on VM flag settings.

This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).

Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890345578

From duke at openjdk.org  Wed Dec 18 15:09:56 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 15:09:56 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@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 with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - move MemTracker::set_done_bootstrap()
 - Update src/hotspot/share/utilities/vmError.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - updates tests and remove old class
 - use ConditionalMutexLocker directly
 - Fix concurrency issue. Add assertions. Update tests.
 - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
   
   This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.

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

Changes: https://git.openjdk.org/jdk/pull/22745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=04
  Stats: 93 lines in 19 files changed: 45 ins; 24 del; 24 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  Wed Dec 18 15:09:57 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 15:09:57 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <7izhKeubKx3xwia21Y50pkjaxYb0Yb781-P-ZbZZ-6I=.c89be21e-28b6-4685-ae60-6e3b29655a12@github.com>

On Wed, 18 Dec 2024 04:31:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates tests and remove old class
>
> src/hotspot/share/runtime/threads.cpp line 530:
> 
>> 528: 
>> 529:   // Once mutexes are ready, we can use NMT locks.
>> 530:   MemTracker::set_done_bootstrap();
> 
> This should be done after the main thread has attached and set the current thread, otherwise if we hit any NMT code that needs the lock it would crash trying to acquire it.

Ok I've moved it until after `initialize_thread_current`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890393548

From ihse at openjdk.org  Wed Dec 18 17:06:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Dec 2024 17:06:02 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>

> 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)

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into remove-build-classpath-exception
 - Update build tools, data and IDE support
 - Update makefiles, autoconf, shell scripts, properties files and configuration files

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

Changes: https://git.openjdk.org/jdk/pull/22104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=01
  Stats: 1994 lines in 555 files changed: 0 ins; 1120 del; 874 mod
  Patch: https://git.openjdk.org/jdk/pull/22104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104

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

From cjplummer at openjdk.org  Wed Dec 18 18:58:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Dec 2024 18:58:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <mPH28lBNaCacYe01SUbFyWRLCwy-N33juiUCG6akkTc=.aba83040-8abf-4989-be3c-835886fe6054@github.com>

On Wed, 18 Dec 2024 03:12:14 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:
> 
>   review: minor tweak in jvmti.xml update

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2512624718

From asemenyuk at openjdk.org  Wed Dec 18 18:58:40 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 18 Dec 2024 18:58:40 GMT
Subject: RFR: 8344191: Build code should not have classpath exception [v2]
In-Reply-To: <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <ijADYihbrxVpLB0pKhpDV8WjUna-2nhvsbx-9qjhukI=.48fc275e-4579-4523-bfba-3992fe0c3d0f@github.com>
Message-ID: <Jzc-zFSvSRq41LPZQUXveoZoJSEMv30oszPC8Qm23mw=.f0743a79-082c-42b7-ac9d-e31515838f5f@github.com>

On Wed, 18 Dec 2024 17:06:02 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)
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into remove-build-classpath-exception
>  - Update build tools, data and IDE support
>  - Update makefiles, autoconf, shell scripts, properties files and configuration files

jpackage changes look good. $0.02

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2512625117

From coleenp at openjdk.org  Wed Dec 18 19:23:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Dec 2024 19:23:39 GMT
Subject: RFR: 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: <4z2P9wv0UyYE7Ct-X0W6VYLVOqpocol7MblNDxlpy6U=.5a09be4a-b10a-4a55-91c2-99abeafef3db@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.

No, bot, this is a new PR.

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

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

From amenkov at openjdk.org  Wed Dec 18 19:37:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 18 Dec 2024 19:37:44 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <kidVU6rc0AJs1On50ARWP1gft9_Uu-17rwkcpcbYwYQ=.b71bc563-1cb7-49e5-9538-a1df111d30c5@github.com>

On Wed, 18 Dec 2024 03:12:14 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:
> 
>   review: minor tweak in jvmti.xml update

I think we need a test for the functionality (a new one or update existing)

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

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2552120263

From amenkov at openjdk.org  Wed Dec 18 19:49:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 18 Dec 2024 19:49:39 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>

On Wed, 18 Dec 2024 03:12:14 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:
> 
>   review: minor tweak in jvmti.xml update

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 500:

> 498:   cname = get_method_class_name(jvmti, jni, method);
> 499: 
> 500:   LOG("\nHit #%d: VirtualThreadUnmount #%d: enabling FramePop for method: %s::%s on virtual thread: %p\n",

The comment needs to be updated as NotifyFramePop is removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1890741942

From kbarrett at openjdk.org  Wed Dec 18 20:01:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 20:01:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>

On Wed, 18 Dec 2024 04:37:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The direct use of CML is functionally correct but requires leaking knowledge to all the use-sites that should not need to know about the actual condition for locking. This really needs to be encapsulated which means we need to be able to subclass CML.

I agree that directly using ConditionalMutexLocker isn't pleasant here, and
one actually does want a dedicated locker for this use-case.  However, that
doesn't mean we need to subclass CML.

> @kbarrett what is needed to make `ConditionalMutexLocker` subclassable?

You don't change ConditionalMutexLocker at all.  Just change how it's used:

class NmtVirtualMemoryLocker : StackObj {
  ConditionalMutexLocker _locker;

public:
  NmtVirtualMemoryLocker()
    : _locker(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag)
  {}
};

MutexLocker can be has-a used similarly for convenience lockers that don't
need the conditionalization.

Note that making MutexLockerImpl noncopyable (as it should be, but that ought
to be addressed separately) would render this noncopyable too (as it should
be).

Note that I was previously wrong when I suggested it might be messy to has-a
use CML; I misremembered and thought these locker things had more operations
than they actually do.

And not that it really matters, but deriving from StackObj with a CML member
doesn't affect the size of this class, because of EBO.

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

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

From kbarrett at openjdk.org  Wed Dec 18 20:01:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 20:01:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
 <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
 <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>
Message-ID: <PhE9qjgKTe1UmdJzTykDwX3DGNBO-DfdOfAO-RW0Nco=.32d3d7f0-63cf-4107-b60f-9dd10dbb0221@github.com>

On Tue, 17 Dec 2024 13:45:38 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> `MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.
>
> Ok I see. I will stop using `ConditionalMutexLocker` as a base class. Instead, I'll just get rid of `NmtVirtualMemoryLocker` and use `ConditionalMutexLocker` directly.

Regarding use of `MutexLockerImpl`, perhaps, though I see nothing in the JBS
issue or the PR that says that.  If it's the name that drives that position
then I think it can easily be argued that it's misnamed, and should be
something like MutexLockerBase.  It *is* nicely designed for use as a base
class, with protected ctors/dtor, making it a convient basis for lockers for
specific use cases. But see my other response about how to has-a use CML (and
MutexLocker) for that purpose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890769789

From dholmes at openjdk.org  Wed Dec 18 22:27:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 22:27:35 GMT
Subject: [jdk24] RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java
 fails with JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
References: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
Message-ID: <5V5F-ptJ6P2LZ7mf4hSliJzeIT1JE1O_EtbBb7zBDLM=.ea08c155-0493-4661-8eaa-c6a09a484c9e@github.com>

On Wed, 18 Dec 2024 07:04:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [414eb6bb](https://github.com/openjdk/jdk/commit/414eb6bb83d092fbcd87d5ab72519b6eb109837f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Plummer on 17 Dec 2024 and was reviewed by Serguei Spitsyn and David Holmes.
> 
> Thanks!

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22805#pullrequestreview-2512981785

From coleenp at openjdk.org  Wed Dec 18 23:04:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Dec 2024 23:04:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
Message-ID: <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>

On Wed, 18 Dec 2024 15:09: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 with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master
>  - move MemTracker::set_done_bootstrap()
>  - Update src/hotspot/share/utilities/vmError.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - updates tests and remove old class
>  - use ConditionalMutexLocker directly
>  - Fix concurrency issue. Add assertions. Update tests.
>  - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
>    
>    This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.

Sorry if I'm repeating other comments, but it looks like a good change but could be a bit less repetition.  Thanks for removing this instance of ThreadCritical.

Oh yes, now I see, sorry I did repeat Kim's suggestion.

src/hotspot/share/runtime/mutexLocker.cpp line 292:

> 290:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
> 291:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 292:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4);

Why is this service-4?  Does it depend on being a rank lower than another lock?  If so, this and the SharedDecoder_lock should be declared below as MUTEX_DEFL and call out that lock.

src/hotspot/share/runtime/os.cpp line 2313:

> 2311:   bool result;
> 2312:   if (MemTracker::enabled()) {
> 2313:     ConditionalMutexLocker cml(NmtVirtualMemory_lock, MemTracker::is_done_bootstrap(), Mutex::_no_safepoint_check_flag);

This pattern is all over.  Can you create a class in nmtSomeHeader like:

class NMTLocker {
    ConditionalMutexLocker cml;
    NMTLocker();
};

in cpp file:
NmtLocker() : _cml(NmtVirtualMemory_lock, MemTracker::is_done_bootstrap(), Mutex::_no_safepoint_check_flag) {}

Or something like that, rather than this be repeated everywhere.  I only skimmed the other comments, so maybe David and Kim said the same thing.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2513014280
PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552430048
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890930186
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890932610

From amenkov at openjdk.org  Thu Dec 19 00:32:40 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 00:32:40 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
Message-ID: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>

On Wed, 18 Dec 2024 03:28:30 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:
> 
>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()

src/hotspot/share/prims/jvmti.xml line 3096:

> 3094:         event will not be generated for any frames.
> 3095:         See the <eventlink id="FramePop"></eventlink> event for details.
> 3096:         <p/>

I think
`The specified thread must be suspended or must be the current thread.`
should be added (as we have in `NotifyFramePop` description)

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 79:

> 77:     _pops->remove_at(idx);
> 78:   }
> 79:   assert(_pops->length() == 0, "sanity check");

Suggestion:

  _pops->clear();

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 261:

> 259:   Thread *current = Thread::current();
> 260: #endif
> 261:   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(current),

Suggestion:

  assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(Thread::current()),

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 44:

> 42: static
> 43: bool isTestThread(JNIEnv *jni, jvmtiEnv *jvmti, jthread thr) {
> 44:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Only thread name is required, `get_thread_name` can be used

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 55:

> 53:   jclass cls;
> 54:   char *mname, *msig, *csig;
> 55:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Only thread name is required, `get_thread_name` can be used

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 81:

> 79:   jclass cls;
> 80:   char *csig;
> 81:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Looks like this is not needed (and inf.name not deallocated)

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 137:

> 135:     LOG("(GetCapabilities) unexpected error: %s (%d)\n", TranslateError(err), err);
> 136:     return JNI_ERR;
> 137:   }

I don't think this is needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890964500
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890974928
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890976875
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890987527
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890987617
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890984746
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890985653

From dholmes at openjdk.org  Thu Dec 19 02:22:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:22:51 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
Message-ID: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>

On Wed, 18 Dec 2024 14:36:41 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 3624:
>> 
>>> 3622: #ifdef ASSERT
>>> 3623:       fileStream fs(stdout);
>>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>> 
>> Why was this change made? tty could be stdout or stderr depending on VM flag settings.
>
> This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).
> 
> Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.

Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1891048323

From dholmes at openjdk.org  Thu Dec 19 02:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:25:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>
Message-ID: <PiJnRk_RKagcnT6YVwXRtyT5kjl7vatJgEyJ20vH0Lg=.a4e6f51b-fd8f-4ec2-bd12-98e09c0f18ad@github.com>

On Wed, 18 Dec 2024 19:58:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> You don't change ConditionalMutexLocker at all. Just change how it's used:

Doh! @kimbarrett  don't know what I was thinking. Thanks

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

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

From syan at openjdk.org  Thu Dec 19 02:50:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 19 Dec 2024 02:50:40 GMT
Subject: [jdk24] Integrated: 8338714:
 vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with
 JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
References: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
Message-ID: <-r-BlqZL9TXHnd_zGTf0T-NtLSSrJknQE8G0fX1fhvQ=.7acb9aca-d970-4851-8ac2-b6df3c91a2c0@github.com>

On Wed, 18 Dec 2024 07:04:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [414eb6bb](https://github.com/openjdk/jdk/commit/414eb6bb83d092fbcd87d5ab72519b6eb109837f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Plummer on 17 Dec 2024 and was reviewed by Serguei Spitsyn and David Holmes.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4aec2d4e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aec2d4ef94876066c29b4372b167bc7747a5c0b
Stats:     26 lines in 3 files changed: 15 ins; 9 del; 2 mod

8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with JTREG_TEST_THREAD_FACTORY=Virtual

Reviewed-by: dholmes
Backport-of: 414eb6bb83d092fbcd87d5ab72519b6eb109837f

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

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

From syan at openjdk.org  Thu Dec 19 02:54:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 19 Dec 2024 02:54:40 GMT
Subject: [jdk24] RFR: 8338714: vmTestbase/nsk/jdb/kill/kill001/kill001.java
 fails with JTREG_TEST_THREAD_FACTORY=Virtual
In-Reply-To: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
References: <C2luL6ESxjUAkFlUhX1_mseeTnYq0tsl54j5YiTltFA=.743ab618-09f2-4b78-ad46-fd72ff3819cb@github.com>
Message-ID: <Oztaog4j8tIVXwQy4VojSxhVu4CdDXgolRl0kgNZM-g=.05b4cc94-3801-4629-b4e4-ce6b96071240@github.com>

On Wed, 18 Dec 2024 07:04:57 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [414eb6bb](https://github.com/openjdk/jdk/commit/414eb6bb83d092fbcd87d5ab72519b6eb109837f) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Chris Plummer on 17 Dec 2024 and was reviewed by Serguei Spitsyn and David Holmes.
> 
> Thanks!

Sorry for violating the 24h code merge limit...

It's clean backport, I think that's all right ?

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

PR Comment: https://git.openjdk.org/jdk/pull/22805#issuecomment-2552666481

From sspitsyn at openjdk.org  Thu Dec 19 03:56:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 03:56:42 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
 <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>
Message-ID: <ATQKSdJMzAha28FxGMlmPUErIEm6Ow-8WaXwKdG_ZQo=.ad587c97-507d-4ac3-b78a-3fb59529b010@github.com>

On Wed, 18 Dec 2024 19:33:05 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: minor tweak in jvmti.xml update
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 500:
> 
>> 498:   cname = get_method_class_name(jvmti, jni, method);
>> 499: 
>> 500:   LOG("\nHit #%d: VirtualThreadUnmount #%d: enabling FramePop for method: %s::%s on virtual thread: %p\n",
> 
> The comment needs to be updated as NotifyFramePop is removed

>  think we need a test for the functionality (a new one or update existing)

I've updated this test to request a duplicated `FramePop` event.

> The comment needs to be updated as NotifyFramePop is removed

I've updated this comment accordingly to the change above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1891097969

From sspitsyn at openjdk.org  Thu Dec 19 04:46:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:46:12 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@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:

  review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/4106c10a..defa6206

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

  Stats: 17 lines in 1 file changed: 11 ins; 3 del; 3 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  Thu Dec 19 04:46:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:46:13 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <PgvC2aBGih8_UOjF7H84gWred8q5IExT8_d5Lk5o02I=.55484bfb-249c-4315-b212-915a010dd5fa@github.com>

On Wed, 18 Dec 2024 03:12:14 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:
> 
>   review: minor tweak in jvmti.xml update

Chris, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2552766218

From sspitsyn at openjdk.org  Thu Dec 19 04:51:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:51:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <3fwf-HTKmKsVKGzQTBlvFXGu04bU9MTjUzN3T7Vrfjg=.04899bd8-87a8-4a0e-8b39-2d234bbb2a94@github.com>

On Wed, 18 Dec 2024 23:51:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmti.xml line 3096:
> 
>> 3094:         event will not be generated for any frames.
>> 3095:         See the <eventlink id="FramePop"></eventlink> event for details.
>> 3096:         <p/>
> 
> I think
> `The specified thread must be suspended or must be the current thread.`
> should be added (as we have in `NotifyFramePop` description)

Nice catch, thanks. Fixed now. Fixed the CSR as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891150755

From sspitsyn at openjdk.org  Thu Dec 19 04:58:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:58:42 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <RbA4vnBHRiHW_TqtSdIERVU7FTXnouuAJPrqAhrD_ls=.2d8c2b92-e99a-406d-b39f-33abc7b33f25@github.com>

On Thu, 19 Dec 2024 00:09:38 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 79:
> 
>> 77:     _pops->remove_at(idx);
>> 78:   }
>> 79:   assert(_pops->length() == 0, "sanity check");
> 
> Suggestion:
> 
>   _pops->clear();

Good suggestion, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891155240

From sspitsyn at openjdk.org  Thu Dec 19 05:10:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:10:38 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <m9XZOTCFsud4-yeQJU6r3BRz78JAkU4NdmqNZGa0ieg=.b6bf57c1-49e4-4a46-8ce5-83097c490d35@github.com>

On Thu, 19 Dec 2024 00:12:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 261:
> 
>> 259:   Thread *current = Thread::current();
>> 260: #endif
>> 261:   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(current),
> 
> Suggestion:
> 
>   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(Thread::current()),

Thank you for the comment. Chris suggested the same.
I've fixed all such places in the file to make it consistent.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 44:
> 
>> 42: static
>> 43: bool isTestThread(JNIEnv *jni, jvmtiEnv *jvmti, jthread thr) {
>> 44:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Only thread name is required, `get_thread_name` can be used

Thanks. Updated now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 55:
> 
>> 53:   jclass cls;
>> 54:   char *mname, *msig, *csig;
>> 55:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Only thread name is required, `get_thread_name` can be used

Thank. Updated now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 81:
> 
>> 79:   jclass cls;
>> 80:   char *csig;
>> 81:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Looks like this is not needed (and inf.name not deallocated)

Good catch. Removed the line now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 137:
> 
>> 135:     LOG("(GetCapabilities) unexpected error: %s (%d)\n", TranslateError(err), err);
>> 136:     return JNI_ERR;
>> 137:   }
> 
> I don't think this is needed

Thanks. Removed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891157836
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891161525
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891162238
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891159383
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891160447

From sspitsyn at openjdk.org  Thu Dec 19 05:14:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:14:38 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
Message-ID: <ogdUk0yZRLFMj_YGelTrroeZM1Pi7ozN2dCjcyiW1-U=.34e11cae-7b8b-43e6-9063-7e5ccd7bfe93@github.com>

On Wed, 18 Dec 2024 03:28:30 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:
> 
>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()

Alex, thank you for review comments! Can you, please, add yourself as CSR reviewer, so I could finalize it?

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

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2552802640

From cjplummer at openjdk.org  Thu Dec 19 05:20:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 19 Dec 2024 05:20:35 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
Message-ID: <v5qPLRu0QqodSIjsLbEXt1sNJR9I4KmK6IA103yPl9w=.e5fc234d-b749-4355-8c75-93f3696f84cd@github.com>

On Thu, 19 Dec 2024 04:46:12 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:
> 
>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2513370366

From sspitsyn at openjdk.org  Thu Dec 19 05:24:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:24:20 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
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: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@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:

  review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/850cafbd..0d762462

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

  Stats: 33 lines in 3 files changed: 1 ins; 21 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 cjplummer at openjdk.org  Thu Dec 19 06:20:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 19 Dec 2024 06:20:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
Message-ID: <fFbG0XcGTOVBs9iYaB4eUrxoguDmb3KhnMQIaLkO8s0=.b93ccb0f-e26e-4650-a890-a40760e81b91@github.com>

On Thu, 19 Dec 2024 05:24: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:
> 
>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2513448235

From coleenp at openjdk.org  Thu Dec 19 12:52:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:34 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
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_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@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 two additional commits since the last revision:

 - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/opto/library_call.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/3106bdd3..cc69a3f2

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

  Stats: 2 lines in 2 files 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 Dec 19 12:52:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:35 GMT
Subject: RFR: 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: <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@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.

The as_int() was because we are using the AccessFlags as an _integral_ value.  I was trying to minimize the effects of the change and the code uses AccessFlags as an integral value.  as_int() returns u2 so I guess that's confusing.  I don't want AccessFlags::get_flags() because that's implies the return is AccessFlags.  I could change the name to as_unsigned_short().  Would that be less confusing?

Thank you David for looking through this change.

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

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

From coleenp at openjdk.org  Thu Dec 19 12:52:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <MTbxg4PoKJ1vWg7AOVsmpQPy8rWmr-zcKHh7JPDf_HE=.fb6c414a-6f9f-48e8-b637-d68922b6679a@github.com>

On Thu, 19 Dec 2024 01:48:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/opto/library_call.cpp line 3874:
> 
>> 3872: Node* LibraryCallKit::generate_interface_guard(Node* kls, RegionNode* region) {
>> 3873:   return generate_klass_flags_guard(kls, JVM_ACC_INTERFACE, 0, region,
>> 3874:                                     Klass::access_flags_offset(), TypeInt::CHAR, T_CHAR);
> 
> Is this CHAR/T_CHAR because you want unsigned?

Yes.  T_SHORT generates the wrong code.

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

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

From coleenp at openjdk.org  Thu Dec 19 12:56:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:56:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>

On Thu, 19 Dec 2024 01:33:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 690:
> 
>> 688:     push(state);
>> 689: 
>> 690:     // Skip if we don't have to unlock. (???is this right???)
> 
> The logic seems consistent with other platforms. Not sure what you are querying.

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.

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

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

From aph at openjdk.org  Thu Dec 19 13:50:43 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 19 Dec 2024 13:50:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
Message-ID: <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>

On Thu, 19 Dec 2024 12:52: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 two additional commits since the last revision:
> 
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 823:

> 821:   {
> 822:     Label done;
> 823:     __ load_unsigned_short(r0, access_flags);

Could you please use `ldrh` rather than `load_unsigned_short` here? `load_unsigned_short` is only used in the termplate interpreter, and is a hangover from the hand-translation from x86.

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

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

From dlong at openjdk.org  Thu Dec 19 19:10:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 19 Dec 2024 19:10:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
Message-ID: <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>

On Thu, 19 Dec 2024 12:52: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 two additional commits since the last revision:
> 
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:

> 689: 
> 690:     // Skip if we don't have to unlock. (???is this right???)
> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.

Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.

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

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

From amenkov at openjdk.org  Thu Dec 19 19:23:36 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 19:23:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
Message-ID: <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>

On Thu, 19 Dec 2024 04:46:12 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:
> 
>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 470:

> 468:     LOG("NotifyFramePop at VirtualThreadUnmount event returned expected JVMTI_ERROR_DUPLICATE\n");
> 469:   } else {
> 470:     LOG("Failed: expected JVMTI_ERROR_DUPLICATE from NotifyFramePop at VirtualThreadUnmount event\n");

Would be nice to log returned value, something like


    LOG("Failed: NotifyFramePop at VirtualThreadUnmount returned %s (%d) instead of expected JVMTI_ERROR_DUPLICATE\n",
           TranslateError(err), err);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893023250

From amenkov at openjdk.org  Thu Dec 19 19:28:40 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 19:28:40 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
Message-ID: <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>

On Thu, 19 Dec 2024 05:24: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:
> 
>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

Marked as reviewed by amenkov (Reviewer).

src/hotspot/share/prims/jvmtiEnvThreadState.hpp line 89:

> 87:   void set(JvmtiFramePop& fp);
> 88:   void clear(JvmtiFramePop& fp);
> 89:   void clear_all();

Need to update copyright year

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

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2515999210
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1893027385

From coleenp at openjdk.org  Thu Dec 19 20:15:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:15:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v3]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@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 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:

 - Fixed bug.
 - Fix merge and compilation errors.
 - Merge branch 'master' into access-flags
 - Renamed AccessFlags.as_int() to as_unsigned_short(), moved masks for method, field and class modifiers into AccessFlags. Change ciFlags to use AccessFlags.
 - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/opto/library_call.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
 - 8339113: AccessFlags can be u2 in metadata

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/cc69a3f2..522ade8c

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

  Stats: 5573 lines in 201 files changed: 3545 ins; 1398 del; 630 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 Dec 19 20:15:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:15:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>
Message-ID: <1hwxD50hCezqeSWdKVroWZhJkP4MiTH0votpw4YBOGs=.3b77bab6-0479-4b7b-aa1f-92b33efe28cd@github.com>

On Thu, 19 Dec 2024 13:48:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 823:
> 
>> 821:   {
>> 822:     Label done;
>> 823:     __ load_unsigned_short(r0, access_flags);
> 
> Could you please use `ldrh` rather than `load_unsigned_short` here? `load_unsigned_short` is only used in the termplate interpreter, and is a hangover from the hand-translation from x86.

Oh, I thought it was quite nice that I didn't have to know the ldrh instruction as a platform independent load_unsigned_short was available.  I can change it in the aarch64 code.

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

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

From coleenp at openjdk.org  Thu Dec 19 20:29:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:29:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
Message-ID: <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>

On Thu, 19 Dec 2024 19:08:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:
> 
>> 689: 
>> 690:     // Skip if we don't have to unlock. (???is this right???)
>> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
> 
> Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.

yes I like testbitdi better.  I found a sample in the templateInterpreterGenerator code.

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

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

From duke at openjdk.org  Thu Dec 19 21:04:51 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:51 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@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 to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/9015d984..f519c3b8

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

  Stats: 37 lines in 12 files changed: 9 ins; 1 del; 27 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 Dec 19 21:04:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
 <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>
Message-ID: <TzUUNf637N1BlrQWnaWunNzzUC1WsKGLJu2cUmywpcU=.0e7f8637-ac52-4389-83d1-ecc9bbdd6617@github.com>

On Wed, 18 Dec 2024 23:01:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master
>>  - move MemTracker::set_done_bootstrap()
>>  - Update src/hotspot/share/utilities/vmError.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - updates tests and remove old class
>>  - use ConditionalMutexLocker directly
>>  - Fix concurrency issue. Add assertions. Update tests.
>>  - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
>>    
>>    This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.
>
> Oh yes, now I see, sorry I did repeat Kim's suggestion.

Thank you @coleenp  and @kimbarrett for the advice on the best way to use `ConditionalMutexLocker` without subclassing it. I've adopted your suggestions.

> src/hotspot/share/runtime/mutexLocker.cpp line 292:
> 
>> 290:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
>> 291:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
>> 292:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4);
> 
> Why is this service-4?  Does it depend on being a rank lower than another lock?  If so, this and the SharedDecoder_lock should be declared below as MUTEX_DEFL and call out that lock.

Yes, it must have a lower rank than "G1Mapper_lock" which is in `G1RegionsSmallerThanCommitSizeMapper`, not in `mutexLocker.cpp`.  I've moved `SharedDecoder_lock` down below as `MUTEX_DEFL` and I've left a comment beside `MUTEX_DEFN(NmtVirtualMemory_lock, PaddedMutex  , service-4);` to explain the rank. Would this be enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2555767690
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893136241

From duke at openjdk.org  Thu Dec 19 21:04:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
 <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
Message-ID: <4GdE0Yc2QNtbtPJeRY1Xr9ruapEWooJ7Q598uO6cHQQ=.788b7c0a-b96e-4de7-9ce2-73e3546207d1@github.com>

On Thu, 19 Dec 2024 02:19:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).
>> 
>> Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.
>
> Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

Ok I see. I've changed it now to use `defaultStream::output_stream()` which should choose either stderr or stdout based on the VM flags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893138320

From dholmes at openjdk.org  Thu Dec 19 21:11:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 21:11:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@github.com>
Message-ID: <0AxZxBjocVYDGFLq6nYhjXOd_TwAJ4qseWsBlYurNnE=.25da67e6-9a51-4229-9118-540d3f775601@github.com>

On Thu, 19 Dec 2024 12:47:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>  I could change the name to as_unsigned_short(). Would that be less confusing?

How about `as_u2()` as that is what it is? (less typing :) ).

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

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

From coleenp at openjdk.org  Thu Dec 19 22:22:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 22:22:13 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v4]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@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:

  Use ldrh rather than load_unsigned_short for aarch64, use testbitdi for ppc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/522ade8c..828e4835

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

  Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 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 Dec 19 22:22:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 22:22:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@github.com>
Message-ID: <QdHSICvr1Z5EplzuPkni6ucHZ93kSZt2TRJHEp6sen4=.12b4e08f-3616-4263-8865-7ddc62f473b5@github.com>

On Thu, 19 Dec 2024 20:15:14 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 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:
> 
>  - Fixed bug.
>  - Fix merge and compilation errors.
>  - Merge branch 'master' into access-flags
>  - Renamed AccessFlags.as_int() to as_unsigned_short(), moved masks for method, field and class modifiers into AccessFlags. Change ciFlags to use AccessFlags.
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
>  - 8339113: AccessFlags can be u2 in metadata

I didn't really like that name since it's the name of the type rather than more of a description of the type returned.  I was able to reduce the number of these by adding some helper functions in AccessFlags.

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

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

From kbarrett at openjdk.org  Thu Dec 19 22:59:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 19 Dec 2024 22:59:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>

On Thu, 19 Dec 2024 21:04:51 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 to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/memTracker.hpp line 72:

> 70:     _done_bootstrap = true;
> 71:   }
> 72: 

I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
opinions from some of the runtime folks like @coleenp and @dholmes-ora .

src/hotspot/share/nmt/memTracker.hpp line 285:

> 283:       ConditionalMutexLocker _cml;
> 284:   public:
> 285:       NmtVirtualMemoryLocker(): _cml(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag){}

Indented 4, but HotSpot style is indent 2.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 341:

> 339:   assert(_reserved_regions != nullptr, "Sanity check");
> 340:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
> 341: 

This line is kind of long.  And why the space before the comma?  And there's a bunch of
these, suggesting there should be a helper to package this up.

src/hotspot/share/utilities/vmError.cpp line 652:

> 650: 
> 651:   BEGIN
> 652:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {

This line is rather long.

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

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2516359489
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893232700
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893228258
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893234021
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893236557

From sspitsyn at openjdk.org  Fri Dec 20 01:17:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:17:49 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v7]
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: <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@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:

  review: updated one copyright year

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

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

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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  Fri Dec 20 01:17:50 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:17:50 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
 <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>
Message-ID: <sBqmQlp0FCHK7W3POfLxci86uYWEkmB8OMRBl7ZlvO8=.bf4020ca-f80d-4898-8c8a-4d8b5c3142a9@github.com>

On Thu, 19 Dec 2024 19:24:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp
>
> src/hotspot/share/prims/jvmtiEnvThreadState.hpp line 89:
> 
>> 87:   void set(JvmtiFramePop& fp);
>> 88:   void clear(JvmtiFramePop& fp);
>> 89:   void clear_all();
> 
> Need to update copyright year

Thanks. Updated now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1893315706

From sspitsyn at openjdk.org  Fri Dec 20 01:23:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:23:22 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@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:

  review: improved one failure logging a little bit

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

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

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

  Stats: 2 lines in 1 file changed: 1 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  Fri Dec 20 01:23:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:23:22 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
 <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>
Message-ID: <wMZdi0hCLF5V7vRYKtrIL6AGjyGpsyTqL5QzqPUeQjA=.151bc32d-12a8-49c4-8885-edbf6878d2e2@github.com>

On Thu, 19 Dec 2024 19:20:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 470:
> 
>> 468:     LOG("NotifyFramePop at VirtualThreadUnmount event returned expected JVMTI_ERROR_DUPLICATE\n");
>> 469:   } else {
>> 470:     LOG("Failed: expected JVMTI_ERROR_DUPLICATE from NotifyFramePop at VirtualThreadUnmount event\n");
> 
> Would be nice to log returned value, something like
> 
> 
>     LOG("Failed: NotifyFramePop at VirtualThreadUnmount returned %s (%d) instead of expected JVMTI_ERROR_DUPLICATE\n",
>            TranslateError(err), err);

Thanks. Updated now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893319148

From sspitsyn at openjdk.org  Fri Dec 20 01:25:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:25:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@github.com>
Message-ID: <GERxLWvEb6A-e0WvP-rR27KEZg1gljDpeXqj2L9DmVo=.7c6adafb-72bb-4552-b37d-b835ead747e0@github.com>

On Tue, 17 Dec 2024 21:41:42 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: improved one failure logging a little bit
>
> src/hotspot/share/prims/jvmti.xml line 3088:
> 
>> 3086:         </error>
>> 3087:         <error id="JVMTI_ERROR_DUPLICATE">
>> 3088:           There is already frame pop event request at the specified depth.
> 
> Suggestion:
> 
>           There is already a frame pop event request at the specified depth.

Thanks. This was fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893320347

From amenkov at openjdk.org  Fri Dec 20 03:07:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 20 Dec 2024 03:07:43 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <YqIY0yZ9IrKN9dYxWJWZDUyDOyP7AHT7hmz2TEJPPGE=.692cd5df-d331-4c28-9187-5ec3f145bcec@github.com>

On Fri, 20 Dec 2024 01:23:22 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:
> 
>   review: improved one failure logging a little bit

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2516639718

From amenkov at openjdk.org  Fri Dec 20 03:08:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 20 Dec 2024 03:08:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v7]
In-Reply-To: <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@github.com>
Message-ID: <z4zUZkaPvv99xYFe8XJasd_fKIs1M2XEpOo6_F-ALj4=.50fab829-6fd6-4a42-8dfe-ea8bf85cdea6@github.com>

On Fri, 20 Dec 2024 01:17:49 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:
> 
>   review: updated one copyright year

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2516644271

From dholmes at openjdk.org  Fri Dec 20 05:05:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Dec 2024 05:05:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v4]
In-Reply-To: <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@github.com>
Message-ID: <S76F1PHjzrzWhrV7AfPYVCphjimVT2wo65Iw3eGjSc4=.82b52756-0aa5-405a-afbe-34a2c5629c02@github.com>

On Thu, 19 Dec 2024 22:22:13 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:
> 
>   Use ldrh rather than load_unsigned_short for aarch64, use testbitdi for ppc.

Things become somewhat clearer once one realizes/recalls that `AccessFlags` do not specifically pertain to access, but to all class/method modifiers as per the various JVMS ACC_XXX constants. We need to restore the leading comment in accessFlags.hpp to read

// AccessFlags is an abstraction over Java ACC flags.

as it originally did.

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

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

From sspitsyn at openjdk.org  Fri Dec 20 05:19:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 05:19:41 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <zMCws6vT1RN8VUeXi0CMkOOE2ufcpCIVVhL8C7ywR0M=.1e03f9c8-5256-4016-a12d-57556c18fa69@github.com>

On Fri, 20 Dec 2024 01:23:22 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:
> 
>   review: improved one failure logging a little bit

Thank you for review, Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2556306574

From coleenp at openjdk.org  Fri Dec 20 13:17:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 13:17:17 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@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:

  Restore ACC in comment.

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

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

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 Dec 20 13:30:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 13:30:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <wiAVa84s2rMcdJkxaX2OGz3CSC0tn87Ai2evu9-DqYA=.0822ca14-1a0a-4b9d-b3a6-1d1b0afd7332@github.com>

On Thu, 19 Dec 2024 01:40:41 GMT, David Holmes <dholmes 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/jfr/leakprofiler/chains/edgeUtils.cpp line 75:
> 
>> 73:     while (!jfs.done()) {
>> 74:       if (offset == jfs.offset()) {
>> 75:         *modifiers = jfs.access_flags().as_int();
> 
> This looks wrong - we want a short and you extracted as an int when it was already a short. ??

I changed as_int() to as_unsigned_short() which hopefully is less confusing, so resolving these conversations/questions.

> src/hotspot/share/oops/method.cpp line 1655:
> 
>> 1653:     return;
>> 1654:   }
>> 1655:   jshort flags = access_flags().as_int();
> 
> Again why the short -> int -> short? And why isn't this unsigned?

The call below takes jshort, so added a checked_cast<>  The top sign bit won't be set because we filter that out (it was ACC_MODULE).

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

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

From coleenp at openjdk.org  Fri Dec 20 15:18:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:18:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>

On Thu, 19 Dec 2024 22:50:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/memTracker.hpp line 72:
> 
>> 70:     _done_bootstrap = true;
>> 71:   }
>> 72: 
> 
> I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
> opinions from some of the runtime folks like @coleenp and @dholmes-ora .

Yes, I agree, bootstrap_done reads better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894060699

From coleenp at openjdk.org  Fri Dec 20 15:40:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:40:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
Message-ID: <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>

On Fri, 20 Dec 2024 15:16:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/nmt/memTracker.hpp line 72:
>> 
>>> 70:     _done_bootstrap = true;
>>> 71:   }
>>> 72: 
>> 
>> I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
>> opinions from some of the runtime folks like @coleenp and @dholmes-ora .
>
> Yes, I agree, bootstrap_done reads better.

There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894069375

From coleenp at openjdk.org  Fri Dec 20 15:40:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:40:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>

On Thu, 19 Dec 2024 21:04:51 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 to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

I had a few minor comments and hopefully easy changes to make.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 421:

> 419:   assert(_reserved_regions != nullptr, "Sanity check");
> 420:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
> 421: 

You could add this to MemTracker class like:
 ```
 inline static void assert_locked();


Then put the body  

void MemTracker::assert_locked() {
  assert(!is_bootstrapping_done() || NmtVirtualMemory_lock->owned_by_self(),
            "should have acquired NmtVirtualMemory_lock");
}

Then all these calls could be MemTracker::assert_locked().

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 631:

> 629: 
> 630:   bool do_allocation_site(const ReservedMemoryRegion* rgn) {
> 631:     assert_lock_strong(NmtVirtualMemory_lock);

So this is past bootstrapping?

src/hotspot/share/runtime/mutexLocker.cpp line 292:

> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions
> 292: #if INCLUDE_CDS

Yes, this looks good.  I see why you couldn't move this one to MUTEX_DEFL.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2517782112
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894080029
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894080796
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894084698

From cjplummer at openjdk.org  Fri Dec 20 16:39:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 20 Dec 2024 16:39:35 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <wX0FP2JL4HvDQg7GKgI4wU1leiBlhBLR3yDmAfBM23o=.fee5ea6f-e19b-40f9-b79e-c175f6c2f9ca@github.com>

On Fri, 20 Dec 2024 01:23:22 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:
> 
>   review: improved one failure logging a little bit

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2517927355

From duke at openjdk.org  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v7]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <BohJMWicbq-8h98uuaSRT1LnmiDU6hIlKapJOWxSXmU=.1476c43b-3a3c-46b2-ac86-e3e585a7ec13@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:

  apply style feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/f519c3b8..5af32fc1

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

  Stats: 28 lines in 5 files changed: 10 ins; 1 del; 17 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  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
Message-ID: <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>

On Fri, 20 Dec 2024 15:24:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, I agree, bootstrap_done reads better.
>
> There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.

Ok I've updated everything to use "bootstrapping_done" instead of "done_bootstrap"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894219662

From duke at openjdk.org  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <UX5tVwjnKyjiQ6Xpokj0txKqR5cIENiFWh7c6msX_nc=.6e2cc942-03ec-4749-b595-0baf2d489a18@github.com>

On Thu, 19 Dec 2024 22:52:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 341:
> 
>> 339:   assert(_reserved_regions != nullptr, "Sanity check");
>> 340:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
>> 341: 
> 
> This line is kind of long.  And why the space before the comma?  And there's a bunch of
> these, suggesting there should be a helper to package this up.

Good point. I've gotten rid of this in favor of the helper that Coleen suggested below.

> src/hotspot/share/utilities/vmError.cpp line 652:
> 
>> 650: 
>> 651:   BEGIN
>> 652:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {
> 
> This line is rather long.

Ok I've broken it up now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218609
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218393

From duke at openjdk.org  Fri Dec 20 17:48:14 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:14 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
Message-ID: <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>

On Fri, 20 Dec 2024 15:33:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 421:
> 
>> 419:   assert(_reserved_regions != nullptr, "Sanity check");
>> 420:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
>> 421: 
> 
> You could add this to MemTracker class like:
>  ```
>  inline static void assert_locked();
> 
> 
> Then put the body  
> 
> void MemTracker::assert_locked() {
>   assert(!is_bootstrapping_done() || NmtVirtualMemory_lock->owned_by_self(),
>             "should have acquired NmtVirtualMemory_lock");
> }
> 
> Then all these calls could be MemTracker::assert_locked().

Good idea. I've adopted your suggestion. Thank you!

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 631:
> 
>> 629: 
>> 630:   bool do_allocation_site(const ReservedMemoryRegion* rgn) {
>> 631:     assert_lock_strong(NmtVirtualMemory_lock);
> 
> So this is past bootstrapping?

I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218073
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894217960

From duke at openjdk.org  Fri Dec 20 17:53:16 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:53:16 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@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:

  convert forgotten assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/5af32fc1..547f07b7

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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 duke at openjdk.org  Fri Dec 20 17:53:16 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:53:16 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <dKT85q2GvWZL1KP2q0yBSimdRNyaGGZRXaqa2fF45g8=.e72c45ce-2e9a-42f6-b1c8-8b8693d8d649@github.com>

On Thu, 19 Dec 2024 22:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/memTracker.hpp line 285:
> 
>> 283:       ConditionalMutexLocker _cml;
>> 284:   public:
>> 285:       NmtVirtualMemoryLocker(): _cml(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag){}
> 
> Indented 4, but HotSpot style is indent 2.

Updated. Thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894224351

From coleenp at openjdk.org  Fri Dec 20 18:12:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 18:12:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
Message-ID: <UMZirYuTPT7H66gOOVkePvR0ROWbGVrp23LwYaZXvHQ=.9c0e3528-1b0e-4d49-bbd6-9e3aa40010fa@github.com>

On Fri, 20 Dec 2024 17:53:16 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:
> 
>   convert forgotten assert

This looks good! Thank you for making these changes.

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

Marked as reviewed by coleenp (Reviewer).

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

From stuefe at openjdk.org  Fri Dec 20 18:26:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:49 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>

On Thu, 19 Dec 2024 21:04:51 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 to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

@roberttoyonaga thank you for taking this on again.

Could you please add a comment somewhere that describes the locking problem we try to solve in all its ugliness? I keep forgetting the details myself.

Something along these lines:

We need locking in NMT for mmap-based allocated (malloc is lockless). Because mmap-based allocations use global data structures. But we also need those lock sections to include the OS-side mmap/munmap calls that caused modifications of said sections. So, `mmap` calls must happen together with their associated `MemTracker::record_reserve`, same for `munmap` and `MemTracker::record_release`. Without locking, NMT may see states that are invalid. For example this order: `T1 calls munmap; T2 calls mmap (same region); T2 calls MemTracker::record_reserve; T1  calls MemTracker::record_release;` would result in NMT seeing a `MemTracker::record_reserve` for a region that, in its opinion, is still occupied.

So we lock, and we want to use Mutex. This has two problems: a) does not work before mutexes have been initialized. b) does not work if Thread::current is NULL. 

(a) is a problem for early mmaps. (Example: polling page setup ?)
(b) is a problem if a thread tries to use mmap but has not yet set Thread::current. This was stack region registration with NMT (because we misuse NMT mmap management for registering stack threads).

src/hotspot/os/windows/os_windows.cpp line 3626:

> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
> 3626: #endif

@roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.

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

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2513685220
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894197615

From stuefe at openjdk.org  Fri Dec 20 18:26:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:49 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
 <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
Message-ID: <s-TbfNJNzCjjHc9lSaKOtYeSOBYCx4_-2vjuNMNJxp8=.c79165a7-6f68-4f0a-a6c2-870f1c3fd56d@github.com>

On Thu, 19 Dec 2024 02:19:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

We should really have a not-blocking variant of `tty` since er use tty for things like debug output when being deep down the stack. In most cases, printing to a small stringStream and then printing the stream content in one go is what I do to get uninterrupted printing. Works well.

@roberttoyonaga pragmatic proposal would be to just remove this debug output, so the whole ASSERT section. I think I added this way back when we had problems investigating Windows reservations writing over each other, but that problem has been fixed and this assert has not been firing for ages.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1891348435

From stuefe at openjdk.org  Fri Dec 20 18:26:50 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
 <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
Message-ID: <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>

On Fri, 20 Dec 2024 17:45:21 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.
>
> Ok I've updated everything to use "bootstrapping_done" instead of "done_bootstrap"

Arguably, MemTracker is the wrong place anyway since the problem it tries to solve is not tied to NMT initialization.

The thought behind the "bootstrap_done" was to make visible that it is safe to not lock since we still run effectively single-threaded. Hotspot loading and CreateJavaVM may happen on different threads, but not at the same time.

We can delay real locking until other threads are starting up. That is somewhere in the middle of VM initialization, but long after NMT has booted. But we can do it also as soon as Mutex initialization is done. 

So we could either move this to the mutex layer and give us a "MutexLocker::all_initialised". In that case, the implicit assumption is that as long as the JVM initializes this before other threads are started. Or, we could move it to the thread subsystem and give us a marker for when we are not single-threaded anymore. I like the former better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894256355

From coleenp at openjdk.org  Fri Dec 20 18:58:47 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 18:58:47 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
Message-ID: <cusGIsMpx_-AQZ2R315Nx2lN3ffHsp68gPedojTdSLo=.63afd895-3ed4-4c29-8002-b471e8d547af@github.com>

On Fri, 20 Dec 2024 17:53:16 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:
> 
>   convert forgotten assert

I was wondering if there was another initialization predicate that could be used instead for this, but it's sort of unclear which to use since there are several, and they're all protecting different actions.  So I thought this was fine for this.

If there was a second need for detecting when it was safe to use MutexLocker, then it seems that moving the initialization flag there would be sensible.

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

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

From duke at openjdk.org  Fri Dec 20 20:19:50 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:19:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v9]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@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:

  remove os::print_memory_mappings. Add comments explaining NMT locking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/547f07b7..9e016b8c

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

  Stats: 17 lines in 2 files changed: 13 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 duke at openjdk.org  Fri Dec 20 20:24:39 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:24:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
Message-ID: <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>

On Fri, 20 Dec 2024 17:22:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/os/windows/os_windows.cpp line 3626:
> 
>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
>> 3626: #endif
> 
> @roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.

Ok I've removed it now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894359621

From duke at openjdk.org  Fri Dec 20 20:57:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:57:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v10]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <WDoPWuQkgHt41WpbFh69HmFnq1S4uhAhM6WRpMcGQnM=.68e8c540-bc32-478f-ac72-6e102fe1059d@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:

  move _bootstrapping_done into MutexLocker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/9e016b8c..223928de

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

  Stats: 29 lines in 7 files changed: 12 ins; 12 del; 5 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  Fri Dec 20 20:57:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:57:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
Message-ID: <mvyTzLqOf2L-pcRnqjs4QbBYG4g6qxh_S0wUvl0hgWw=.70c7dc0a-57fd-4fd8-909e-058fe522298b@github.com>

On Fri, 20 Dec 2024 18:23:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> @roberttoyonaga thank you for taking this on again.
> 
> Could you please add a comment somewhere that describes the locking problem we try to solve in all its ugliness? I keep forgetting the details myself.
> 
> Something along these lines:
> 
> We need locking in NMT for mmap-based allocated (malloc is lockless). Because mmap-based allocations use global data structures. But we also need those lock sections to include the OS-side mmap/munmap calls that caused modifications of said sections. So, `mmap` calls must happen together with their associated `MemTracker::record_reserve`, same for `munmap` and `MemTracker::record_release`. Without locking, NMT may see states that are invalid. For example this order: `T1 calls munmap; T2 calls mmap (same region); T2 calls MemTracker::record_reserve; T1  calls MemTracker::record_release;` would result in NMT seeing a `MemTracker::record_reserve` for a region that, in its opinion, is still occupied.
> 
> So we lock, and we want to use Mutex. This has two problems: a) does not work before mutexes have been initialized. b) does not work if Thread::current is NULL. 
> 
> (a) is a problem for early mmaps. (Example: polling page setup ?)
> (b) is a problem if a thread tries to use mmap but has not yet set Thread::current. This was stack region registration with NMT (because we misuse NMT mmap management for registering stack threads).

Thank you @tstuefe  for the feedback! I've added a comment explaining why the locking is necessary and the considerations surrounding it.  Please let me know if I should change the wording or if you think I missed any details. 

As for other initialization predicates that could be reused instead of  `_bootstrapping_done`,   maybe `is_init_completed()`  could also accomplish the same task. However, it uses atomics and gets set much later in VM initialization, whereas `_bootstrapping_done` can be set immediately after current thread is attached.  

So I think it makes the most sense to either keep `_bootstrapping_done` inside `MemTracker` or move it into `MutexLocker`. For now, I've adopted your suggestion to moved it into `MutexLocker` so that it can be used more generally in places other than NMT in the future.

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

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

From duke at openjdk.org  Fri Dec 20 21:29:18 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 21:29:18 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@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:

  move boostrapping_done flag into Mutex from MutexLocker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/223928de..1909279c

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

  Stats: 26 lines in 7 files changed: 10 ins; 10 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 dlong at openjdk.org  Fri Dec 20 21:37:38 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 20 Dec 2024 21:37:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>

On Fri, 20 Dec 2024 13:17:17 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:
> 
>   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?

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

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

From kbarrett at openjdk.org  Sat Dec 21 17:07:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 21 Dec 2024 17:07:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
Message-ID: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>

On Fri, 20 Dec 2024 21:29:18 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:
> 
>   move boostrapping_done flag into Mutex from MutexLocker

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/threadStackTracker.cpp line 55:

> 53:   align_thread_stack_boundaries_inward(base, size);
> 54: 
> 55:   MemTracker::MemTracker::NmtVirtualMemoryLocker nvml;

Too many "MemTracker"s here?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 632:

> 630:     if (Mutex::is_bootstrapping_done()) {
> 631:       assert_lock_strong(NmtVirtualMemory_lock);
> 632:     }

It seems like this can use `MemTracker::assert_locked()`, since that is conditioned on bootstrapping state.

src/hotspot/share/runtime/mutex.hpp line 222:

> 220:   }
> 221:  private:
> 222:   static bool _bootstrapping_done;

A description of what these mean would be nice. It seems to be mutex_init completed + threading
initialization completed?

src/hotspot/share/runtime/mutexLocker.cpp line 291:

> 289:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions

Is it really okay for nmt to use a VM mutex? That means relevant functions can
only be called from a VM thread. In particular, what happens if we get into
the error handler because of a signal on a non-VM thread, or something
similarly weird.

This is also replacing the PlatformMutex that was being used by
MemoryFileTracker. I don't know why that was using a PlatformMutex, but I
presume there was a reason. It was doing so in the initial version of
JDK-8312132. Looking back through the development commits, is see these two in
sequence:

3472573 Introduce a separate Mutex for MemoryFileTracker
46f10f6 Use own PlatformMutex instead

I found no discussion about that choice in the PR. Maybe it was because of
problems determining the needed lock rank? (The original VM mutex had
Mutex::service rank. That's apparently too high, as discussed in this change.)
Or maybe there was some other reason?

I'll ask @jdksjolen about this, though holidays...

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

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2518602318
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894576359
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894576955
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894652359
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894657610

From dholmes at openjdk.org  Sun Dec 22 20:46:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 22 Dec 2024 20:46:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
 <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
 <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>
Message-ID: <SBXFXJnsjQHShRNn9P_Q3TijbVi9uQhZUhk2Z9COuF8=.7367f29e-9333-430f-861d-8670cf495160@github.com>

On Fri, 20 Dec 2024 18:22:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hotspot loading and CreateJavaVM may happen on different threads

??? What are you referring to as "hotspot loading"? To me that _is_ CreateJavaVM.

> Or, we could move it to the thread subsystem

We already have `Threads::number_of_threads()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895052378

From stuefe at openjdk.org  Mon Dec 23 08:08:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
 <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>
Message-ID: <Lschz_z7Wg4alo2vOwo8uUDEVgDSVu1leXfwJEeJkNg=.643e9514-99e9-4312-8de5-f4e157b656cf@github.com>

On Fri, 20 Dec 2024 20:21:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 3626:
>> 
>>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>>> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
>>> 3626: #endif
>> 
>> @roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.
>
> Ok I've removed it now

You can also remove the ifdef assert, since assert() only fires if ASSERT is defined

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894655240

From stuefe at openjdk.org  Mon Dec 23 08:08:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v9]
In-Reply-To: <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@github.com>
Message-ID: <6F00QUi_ttcWN1bxlpiPYQ_GmgYBd9tDqCiA_c5A0sk=.7f47c1c4-2422-4e82-9ba4-8805ff02afdf@github.com>

On Fri, 20 Dec 2024 20:19: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:
> 
>   remove os::print_memory_mappings. Add comments explaining NMT locking

src/hotspot/share/nmt/memTracker.hpp line 300:

> 298:    * attempting to lock until initialization is finished. Lack of synchronization here should not be a problem since it
> 299:    * is single threaded at that point in time anyway.
> 300:    */

good comment

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895374056

From stuefe at openjdk.org  Mon Dec 23 08:08:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
 <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
Message-ID: <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>

On Fri, 20 Dec 2024 17:43:29 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.


It could be called as part of the NMT report error reporting during early JVM initialization => between NMT bootstrap and Mutex system startup. That report is only written though if NMT is enabled, and that requires NMT to have been bootstrapped. Is NMT bootstrap after Mutex system bootstrap? Then we are fine here.

Man, I start warming up to your original idea of just using a plain OS-side mutex for NMT lockes, @roberttoyonaga . One that always works. Problem is missing deadlock detection.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895379917

From stuefe at openjdk.org  Mon Dec 23 08:08:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
 <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
Message-ID: <3n0ir33zcUWsWk13ncRu4dfnMDUqfUcHmVkJbXI04gU=.66b705fd-d1fb-4175-b7b2-f637ffdc21ec@github.com>

On Sat, 21 Dec 2024 16:57:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move boostrapping_done flag into Mutex from MutexLocker
>
> src/hotspot/share/runtime/mutexLocker.cpp line 291:
> 
>> 289:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
>> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
>> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions
> 
> Is it really okay for nmt to use a VM mutex? That means relevant functions can
> only be called from a VM thread. In particular, what happens if we get into
> the error handler because of a signal on a non-VM thread, or something
> similarly weird.
> 
> This is also replacing the PlatformMutex that was being used by
> MemoryFileTracker. I don't know why that was using a PlatformMutex, but I
> presume there was a reason. It was doing so in the initial version of
> JDK-8312132. Looking back through the development commits, is see these two in
> sequence:
> 
> 3472573 Introduce a separate Mutex for MemoryFileTracker
> 46f10f6 Use own PlatformMutex instead
> 
> I found no discussion about that choice in the PR. Maybe it was because of
> problems determining the needed lock rank? (The original VM mutex had
> Mutex::service rank. That's apparently too high, as discussed in this change.)
> Or maybe there was some other reason?
> 
> I'll ask @jdksjolen about this, though holidays...

@kimbarrett This was my proposal, but I now doubt whether it was a good proposal. My reasoning was that we want to have deadlock detection (NMT locking is somewhat "midlevel" since the section it encompasses can be large) and things like "assert_lock_strong". Admittedly, the latter can be easily done differently with a raw OS-side mutex.

After thinking about this more, the advantages of a raw OS-side mutex would be:
- not having to think about initialization order
- can be statically initialized at least on Posix
- it works when we are called from a non-VM thread - ideas both I and @jdksjolen had would be extending NMT to outside, which opens us to being called both long before VM init and outside any VM thread

Not sure anymore what to think. What do others think? Go back to Roberts original proposal?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895386033

From qxing at openjdk.org  Mon Dec 23 09:50:10 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 23 Dec 2024 09:50:10 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
Message-ID: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>

This patch fixes unmatched brackets in some source files.

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

Commit messages:
 - Fix unmatched brackets in source files.

Changes: https://git.openjdk.org/jdk/pull/22861/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346773
  Stats: 2244 lines in 25 files changed: 2211 ins; 2 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

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

From erikj at openjdk.org  Mon Dec 23 14:05:35 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 23 Dec 2024 14:05:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source 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: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@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 source files.

I can really only review the doc files and the Makefile.

doc/hotspot-unit-tests.md line 175:

> 173: there is no need to have them in error messages. Asserts print only
> 174: compared values, they do not print any of interim variables, e.g.
> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only

Looking at this expression, I believe the intention is this.
Suggestion:

`ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

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

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2520648246
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895785097

From duke at openjdk.org  Mon Dec 23 14:30:43 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 14:30:43 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
 <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
Message-ID: <QBH7xfLoxwZP_Vj1l2EWCF78I6dQFZQBthy3TJnEFQc=.25cb7bbc-2d6a-4f17-8b2a-774def040906@github.com>

On Sat, 21 Dec 2024 07:16:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move boostrapping_done flag into Mutex from MutexLocker
>
> src/hotspot/share/nmt/threadStackTracker.cpp line 55:
> 
>> 53:   align_thread_stack_boundaries_inward(base, size);
>> 54: 
>> 55:   MemTracker::MemTracker::NmtVirtualMemoryLocker nvml;
> 
> Too many "MemTracker"s here?

thank you for spotting. I'll remove that

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 632:
> 
>> 630:     if (Mutex::is_bootstrapping_done()) {
>> 631:       assert_lock_strong(NmtVirtualMemory_lock);
>> 632:     }
> 
> It seems like this can use `MemTracker::assert_locked()`, since that is conditioned on bootstrapping state.

`assert_lock_strong`  skips checking the lock ownership if `DebuggingContext::is_enabled() || VMError::is_error_reported()`. `MemTracker::assert_locked()` does not do that.  Is that ok?

> src/hotspot/share/runtime/mutex.hpp line 222:
> 
>> 220:   }
>> 221:  private:
>> 222:   static bool _bootstrapping_done;
> 
> A description of what these mean would be nice. It seems to be mutex_init completed + threading
> initialization completed?

Yes, that's right. I'll add a comment describing this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895809641
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895811421
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895812737

From duke at openjdk.org  Mon Dec 23 14:30:44 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 14:30:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
 <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
 <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>
Message-ID: <mKKgJkD_4QVGje73WRrviM-KEqq11juDenhV7VWV3ZU=.6bfee217-dfff-4b78-9585-dc7d887ba07a@github.com>

On Mon, 23 Dec 2024 07:58:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.
>
>> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.
> 
> 
> It could be called as part of the NMT report error reporting during early JVM initialization => between NMT bootstrap and Mutex system startup. That report is only written though if NMT is enabled, and that requires NMT to have been bootstrapped. Is NMT bootstrap after Mutex system bootstrap? Then we are fine here.
> 
> Man, I start warming up to your original idea of just using a plain OS-side mutex for NMT lockes, @roberttoyonaga . One that always works. Problem is missing deadlock detection.

`MemTracker::initialize();` is called before Mutexes are ready. So it seems like that means this `assert_lock_strong` can be called before Mutexes can be used. So we do need that check for `MemTracker::is_bootstrapping_done()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895808205

From duke at openjdk.org  Mon Dec 23 15:26:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 15:26:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@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:

  comments, remove unneeded ifdef, remove typo

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

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

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

  Stats: 7 lines in 3 files changed: 4 ins; 2 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 jlu at openjdk.org  Mon Dec 23 17:13:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Dec 2024 17:13:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source 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: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@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 source files.

make/data/cldr/common/main/kn.xml line 1085:

> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>

Hi, we would not modify the contents of upstream data from CLDR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895964999

From kbarrett at openjdk.org  Mon Dec 23 19:36:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:36:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source 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: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@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 source files.

I strongly suggest avoiding omnibus changes like this when possible (which it
is here). Just because it's all about one "kind" of change doesn't make it a
cohesive change. This is touching many distinct areas of the JDK, and several
different languages as well. That makes it harder to review and to manage the
review, because it is large and affects a wide range of areas, so may need
many reviewers. And the whole thing might get stalled by discussion of one
piece.

There is also no mention of what testing has been done for this PR. Some of
the changes are in executable code, and need to be tested.

I think that all of the files in make/data/cldr/common are from the Unicode
Consortium, and should not be modified here.

doc/hotspot-unit-tests.html line 248:

> 246: so there is no need to have them in error messages. Asserts print only
> 247: compared values, they do not print any of interim variables, e.g.
> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>

This file is generated from the .md file, and should not be edited directly.

test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:

> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
> 49:     $(TESTLIBRARY_DIR)/jtreg \
> 50:     -maxdepth 1 -name '*.java')

I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
close-paren?

test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:

> 63:           @page { margin: 0.1in; }
> 64: 
> 65:           }

Does this affect the behavior of the test this is part of?

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

I can't tell whether anything was changed in this file other than the modification of all the end of
line indicators. I've no idea whether changing those is appropriate or not, but this file came from
a 3rd party, so might not be appropriate to change here.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

Does this change affect the behavior of the associated test(s)?

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2521031190
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896040106
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896050113
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896061137
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064083
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064580

From kbarrett at openjdk.org  Mon Dec 23 19:45:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:45:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>

On Mon, 23 Dec 2024 19:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.

And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

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

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

From prr at openjdk.org  Mon Dec 23 20:33:34 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:34 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <PFz3alfIjjgTruEYo0zh1sF7VlmWQfYSm5zVAbgWMZM=.16f79e13-f7ca-4311-81f5-a66874094766@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

I think at the very least this needs multiple reviewers. Even 2 isn't enough considering it is so cross-area.
It went to 7 different mailing lists, so that should tell you something !

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

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

From prr at openjdk.org  Mon Dec 23 20:33:36 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>

On Mon, 23 Dec 2024 19:30:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> Does this change affect the behavior of the associated test(s)?

I was also wondering how this was tested.

> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> I can't tell whether anything was changed in this file other than the modification of all the end of
> line indicators. I've no idea whether changing those is appropriate or not, but this file came from
> a 3rd party, so might not be appropriate to change here.

+1 to all of that. This change is un-reviewable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100629
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100936

From prr at openjdk.org  Mon Dec 23 22:18:35 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 22:18:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
Message-ID: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>

On Mon, 23 Dec 2024 20:29:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
>> 
>>> 1: <?xml version="1.0" encoding="UTF-8"?>
>>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
>> 
>> Does this change affect the behavior of the associated test(s)?
>
> I was also wondering how this was tested.

FYI, the way to test this is ..
cd test/jdk
jtreg sanity/client/SwingSet/src/TableDemoTest.java

I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896162028

From qxing at openjdk.org  Tue Dec 24 03:26:23 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:23 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
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: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>

> This patch fixes unmatched brackets in some source files.

Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:

 - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
 - Do not touch files in test.
 - Do not touch upstream data from CLDR.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/540312c4..ec3e6aa5

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

  Stats: 2235 lines in 19 files changed: 2 ins; 2211 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

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

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <qToKH3NIiVa0fL7Lyd8VoUIjdMf1kohn_JEMNJE5A4s=.1fd147f1-fe89-46f0-8ffa-57aeef5d2d24@github.com>

On Mon, 23 Dec 2024 18:57:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.html line 248:
> 
>> 246: so there is no need to have them in error messages. Asserts print only
>> 247: compared values, they do not print any of interim variables, e.g.
>> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>
> 
> This file is generated from the .md file, and should not be edited directly.

Updated both `.md` and `.html` using `make update-build-docs` in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896332803

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
Message-ID: <4QfTqVdt_-vwDpQQAaeiElZLvHDDBabcyBtISbLrmPo=.7aa033a5-d09b-4193-9d2e-1336167a10ce@github.com>

On Mon, 23 Dec 2024 14:00:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.md line 175:
> 
>> 173: there is no need to have them in error messages. Asserts print only
>> 174: compared values, they do not print any of interim variables, e.g.
>> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only
> 
> Looking at this expression, I believe the intention is this.
> Suggestion:
> 
> `ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

Thanks for the suggestion, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331528

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
Message-ID: <rjeNtZS_8Tl4gLjpg0W0gwCSOIHIHcU0VfNB1_P9D1Y=.69d45611-fded-4d4d-96d5-89e33ab6addc@github.com>

On Mon, 23 Dec 2024 17:11:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> make/data/cldr/common/main/kn.xml line 1085:
> 
>> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
>> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
>> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>
> 
> Hi, we would not modify the contents of upstream data from CLDR.

Sorry, I've reverted these changes in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331971

From qxing at openjdk.org  Tue Dec 24 03:32:36 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:32:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>

On Mon, 23 Dec 2024 19:13:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
> 
>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>> 50:     -maxdepth 1 -name '*.java')
> 
> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
> close-paren?

I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.

I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

> test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:
> 
>> 63:           @page { margin: 0.1in; }
>> 64: 
>> 65:           }
> 
> Does this affect the behavior of the test this is part of?

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896336118
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896337303

From qxing at openjdk.org  Tue Dec 24 03:35:47 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:35:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
 <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
Message-ID: <bs7fuVeUaVtrunvJFhOMsam8pz9Oi43_cTdEk0c2Wsc=.276f1181-a283-4d29-b8b5-bbe45a4eccf6@github.com>

On Mon, 23 Dec 2024 22:16:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> I was also wondering how this was tested.
>
> FYI, the way to test this is ..
> cd test/jdk
> jtreg sanity/client/SwingSet/src/TableDemoTest.java
> 
> I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

For safety reasons I've restored this file as well as all the files in unit tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896338401

From erikj at openjdk.org  Tue Dec 24 14:57:36 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 24 Dec 2024 14:57:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <LWyDWVBvPHM-9HkpB7pI5vh4Ppr-pNufCTbqGlBEhBE=.9917b618-876d-4744-8d1f-f59b137984c8@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

I've reviewed doc/hotspot-unit-tests.* and the Makefile.

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

Marked as reviewed by erikj (Reviewer).

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

From liach at openjdk.org  Tue Dec 24 15:48:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
Message-ID: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>

On Tue, 24 Dec 2024 03:28:31 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
>> 
>>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>>> 50:     -maxdepth 1 -name '*.java')
>> 
>> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
>> close-paren?
>
> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
> 
> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896838026

From liach at openjdk.org  Tue Dec 24 15:48:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <dlNpmJp8MDFrFYWDsN0BOkDNw5MOiJB1AoEx6VfQC5g=.794bdb89-b349-49a3-88aa-9f41dc5bfc23@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

Thanks for the ctw fix.

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

Marked as reviewed by liach (Reviewer).

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

From stooke at openjdk.org  Tue Dec 24 16:21:19 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 24 Dec 2024 16:21:19 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java failing on
 Windows with "Stack base not yet set for thread id"
Message-ID: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@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.

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

Commit messages:
 - 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: https://git.openjdk.org/jdk/pull/22870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346717
  Stats: 13 lines in 2 files changed: 12 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 kbarrett at openjdk.org  Tue Dec 24 20:30:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 20:30:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
Message-ID: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>

On Tue, 24 Dec 2024 15:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
>> 
>> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.
>
> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
fixing it in isolation, and backporting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896952109

From kbarrett at openjdk.org  Tue Dec 24 22:25:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:25:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
Message-ID: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>

On Tue, 24 Dec 2024 20:27:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.
>
> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
> fixing it in isolation, and backporting that.

The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
this Makefile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896981987

From kbarrett at openjdk.org  Tue Dec 24 22:36:47 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:36:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <5RJCjU8mibDWRUFIu_5QaivS78cZGFT1ECjS4_f2Z8E=.a8ff6fd5-cba0-40f5-b754-9bdb6f7e8d4b@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

The fix for the ctw Makefile should not be included in this PR.  It's a bug, and needs
to be fixed separately and backported to 24 to fix the introduction there via the
backport of JDK-8334733 from 25 to 24, without dragging the rest of this back to 24.

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

Changes requested by kbarrett (Reviewer).

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

From prr at openjdk.org  Tue Dec 24 23:39:14 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Dec 2024 23:39:14 GMT
Subject: RFR: 8346829: Problem list com/sun/jdi/ReattachStressTest.java &
 ProcessAttachTest.java on Linux
Message-ID: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>

I'd like to problem list two tests which have started failing very frequently

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

Commit messages:
 - 8346829

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

PR: https://git.openjdk.org/jdk/pull/22877

From prr at openjdk.org  Tue Dec 24 23:39:14 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Dec 2024 23:39:14 GMT
Subject: RFR: 8346829: Problem list com/sun/jdi/ReattachStressTest.java &
 ProcessAttachTest.java on Linux
In-Reply-To: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
References: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
Message-ID: <4DDdSxIbU4qGWbZVfGavpuU-LNocP8SuEZDERgzQ4LM=.c5dd276a-7d82-4e3a-9cf8-5765e8a0fe80@github.com>

On Tue, 24 Dec 2024 22:55:12 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd like to problem list two tests which have started failing very frequently

bit of a guess ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22877#issuecomment-2561490332

From lmesnik at openjdk.org  Wed Dec 25 00:29:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 00:29:36 GMT
Subject: RFR: 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: <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@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.

Changes requested by lmesnik (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

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.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2522246825
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1897011178

From lmesnik at openjdk.org  Wed Dec 25 00:42:39 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 00:42:39 GMT
Subject: RFR: 8346829: Problem list com/sun/jdi/ReattachStressTest.java &
 ProcessAttachTest.java on Linux
In-Reply-To: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
References: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
Message-ID: <JKOwCpjyE3WvtLNYvuuF5lhFW1ZzYNCW6EELMKm3BAM=.3f6bbb26-bf4e-42ee-a12f-c7126e3da3ad@github.com>

On Tue, 24 Dec 2024 22:55:12 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd like to problem list two tests which have started failing very frequently

Looks good and trivial. Thanks for fixing this!

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22877#pullrequestreview-2522249549

From prr at openjdk.org  Wed Dec 25 00:42:39 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Dec 2024 00:42:39 GMT
Subject: Integrated: 8346829: Problem list com/sun/jdi/ReattachStressTest.java
 & ProcessAttachTest.java on Linux
In-Reply-To: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
References: <Lu0Nfwr5lcZKkFqYum1xLyvqzsk4T7eCmCS2zoMsvG0=.225eb76f-1db3-4100-affe-79af6fd9a0ee@github.com>
Message-ID: <04ZkftYpurvLk_sEMw-j-fphd8PbMNFo0QIzCYUeIuY=.8d5d7594-08d3-48c9-9699-b14de8796a26@github.com>

On Tue, 24 Dec 2024 22:55:12 GMT, Phil Race <prr at openjdk.org> wrote:

> I'd like to problem list two tests which have started failing very frequently

This pull request has now been integrated.

Changeset: 4fc445d1
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fc445d12b4dabd5ce3a6deb23ca6e4fea323620
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8346829: Problem list com/sun/jdi/ReattachStressTest.java & ProcessAttachTest.java on Linux

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/22877

From lmesnik at openjdk.org  Wed Dec 25 01:47:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 01:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
 <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
Message-ID: <7rkkA5WQNof4ipfVB0NnpXU1o_nHsPmW3rulRPp78ZU=.593fc62d-f6ae-4885-b6db-09822cfb45ef@github.com>

On Tue, 24 Dec 2024 22:22:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
>> fixing it in isolation, and backporting that.
>
> The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
> or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
> think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
> specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
> this Makefile.

This makefile is not used by jtreg tests. The ctw code is compiled with 
`@library /test/lib / /testlibrary/ctw/src`
so jtreg compiled the ctw library files itself.
This makefile might be used for standalone build if needed.
Thanks for fixing this!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1897036236

From qxing at openjdk.org  Wed Dec 25 02:34:16 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:34:16 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
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: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>

> This patch fixes unmatched brackets in some source files.

Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:

  Revert fix in the CTW Makefile.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/ec3e6aa5..7f85c5e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

PR: https://git.openjdk.org/jdk/pull/22861

From qxing at openjdk.org  Wed Dec 25 02:37:41 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:37:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <lfbJHjq8KIOjVlG1hsR_nMbCSJ98DVHO8psUkvciZ88=.afbd9575-ea1a-4a19-a483-999917c01510@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I strongly suggest avoiding omnibus changes like this when possible (which it
>> is here). Just because it's all about one "kind" of change doesn't make it a
>> cohesive change. This is touching many distinct areas of the JDK, and several
>> different languages as well. That makes it harder to review and to manage the
>> review, because it is large and affects a wide range of areas, so may need
>> many reviewers. And the whole thing might get stalled by discussion of one
>> piece.
>> 
>> There is also no mention of what testing has been done for this PR. Some of
>> the changes are in executable code, and need to be tested.
>> 
>> I think that all of the files in make/data/cldr/common are from the Unicode
>> Consortium, and should not be modified here.
>
>> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

@kimbarrett @liach Thanks for your suggestions!

I've moved the fix for the CTW Makefile to a separate pull request: https://github.com/openjdk/jdk/pull/22878, please check it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2561558033

From kbarrett at openjdk.org  Wed Dec 25 04:57:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 25 Dec 2024 04:57:39 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source 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: <RqSpJLzAEPtdnM_px2zUHBK8OWqoSsBiQABho0fLUAY=.f409be95-8db4-4e5b-9337-313a7256461e@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 source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522326924

From amitkumar at openjdk.org  Wed Dec 25 07:48:36 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 25 Dec 2024 07:48:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>

On Fri, 20 Dec 2024 13:17:17 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:
> 
>   Restore ACC in comment.

Hi @coleenp, 

This is breaking s390x build. Would you please added below patch :) 

[s390_port.patch](https://github.com/user-attachments/files/18244370/s390_port.patch)

-------------

Changes requested by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2522399559

From schernyshev at openjdk.org  Wed Dec 25 08:20:39 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 25 Dec 2024 08:20:39 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v9]
In-Reply-To: <6x7XcQ3isAojum3gJl0uNQ23xQvjZJMUhCaTAna7uSk=.2d2924fa-d92e-4167-bd81-b7afd11aab3d@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <lsR5JNyM8Wf_Zi5rIYxeR0rK1qg9i5vuSg1Nt27u-_I=.ca73e8cc-b1af-4b38-be60-3863712d184a@github.com>
 <hDh2OBUQVTPFi5KPz45W5t1v8WAotzDfZeO938wsrTQ=.126d8301-6569-4c22-8d0c-37f6b3666b7e@github.com>
 <Gjqtsgk6O12U7FcE11QmMumtom6KfBsBsBdSG_mxZk0=.407eaf2e-1c72-4ead-b196-2ab94b254b3a@github.com>
 <6x7XcQ3isAojum3gJl0uNQ23xQvjZJMUhCaTAna7uSk=.2d2924fa-d92e-4167-bd81-b7afd11aab3d@github.com>
Message-ID: <W-ULjwTeBn3CJ1DfWYQOh4-u8sexeVwfs-08hT1K9cA=.fd5524bf-c265-4784-816c-34eef9ed5528@github.com>

On Wed, 11 Dec 2024 15:24:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Would you recommand also to include the paths in that warning? Something like
>> ```cgroup controller path at '/sys/fs/cgroup' seems to have moved to '../../test', detected limits won't be accurate```
>> This way it will have all the necessary information to investigate customer cases.
>
> Seems fine yes.

@jerboaa Could you please take a look?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1897191131

From mdoerr at openjdk.org  Wed Dec 25 16:31:35 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:31:35 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
 <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>
Message-ID: <U9dvIXFJj4I-Tzl2u6qaZXU3KsiSAbsgumWRrTJUVzc=.e66c9353-507d-4dff-8b7b-8088b3af39df@github.com>

On Thu, 19 Dec 2024 20:27:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:
>> 
>>> 689: 
>>> 690:     // Skip if we don't have to unlock. (???is this right???)
>>> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
>> 
>> Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.
>
> yes I like testbitdi better.  I found a sample in the templateInterpreterGenerator code.

Right, Bit 0 refers to the MSB on IBM platforms (not only AIX). Using `testbitdi` is also fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897419817

From mdoerr at openjdk.org  Wed Dec 25 16:36:44 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:36:44 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@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>
Message-ID: <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>

On Thu, 19 Dec 2024 12:54:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 690:
>> 
>>> 688:     push(state);
>>> 689: 
>>> 690:     // Skip if we don't have to unlock. (???is this right???)
>> 
>> The logic seems consistent with other platforms. Not sure what you are querying.
>
> 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.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897420985

From mdoerr at openjdk.org  Wed Dec 25 16:42:36 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:42:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>

On Fri, 20 Dec 2024 13:17:17 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:
> 
>   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.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897422214

From aph at openjdk.org  Wed Dec 25 22:37:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 25 Dec 2024 22:37:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
Message-ID: <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>

On Wed, 25 Dec 2024 07:46:00 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This is breaking s390x build. Would you please added below patch :)

Maybe `testbit_16` isn't the rbest name. Perhaps `testbit_ushort` is better?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2562014053

From amitkumar at openjdk.org  Thu Dec 26 04:12:36 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 26 Dec 2024 04:12:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
 <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>
Message-ID: <GxGzV5ErM8HjQ7P9Y1Htbpv1HcdPs_1w2Jye8Ge4i-4=.0933e662-e346-48b2-af68-85e74fe7b512@github.com>

On Wed, 25 Dec 2024 22:35:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > This is breaking s390x build. Would you please added below patch :)
> 
> Maybe `testbit_16` isn't the rbest name. Perhaps `testbit_ushort` is better?

Sure, updated patch: 
[s390_port_updated.patch](https://github.com/user-attachments/files/18249438/s390_port_updated.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2562134245

From alanb at openjdk.org  Thu Dec 26 07:30:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Dec 2024 07:30:42 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source 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: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@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 source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522898115

From qxing at openjdk.org  Thu Dec 26 07:47:37 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 26 Dec 2024 07:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
 <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
Message-ID: <IUYSixbdrVq_VN1BgMfj3kE9DJb17d4aQ6_eg1w_-7U=.1841076e-3ed7-432c-af9b-a38bd4c6e8e4@github.com>

On Thu, 26 Dec 2024 07:27:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert fix in the CTW Makefile.
>
> The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

@AlanBateman Thanks for the review! I updated the title of the JBS issue and this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2562270247

From duke at openjdk.org  Fri Dec 27 18:20:41 2024
From: duke at openjdk.org (duke)
Date: Fri, 27 Dec 2024 18:20:41 GMT
Subject: Withdrawn: 8204681: Option to include timestamp in hprof filename
In-Reply-To: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
Message-ID: <M1y0s9LPKxMj2hUZ_uDWGmaYjRBUXXfUJWh-UQipE_w=.6eedc7ec-e0e5-4ef8-9054-cd6440a68a8c@github.com>

On Tue, 13 Aug 2024 15:07:17 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681) enabling support for timestamp expansion in filenames specified in `-XX:HeapDumpPath` using `%t`. 
> 
> As mentioned in this comments for this issue, this is somewhat related to [8334492](https://bugs.openjdk.org/browse/JDK-8334492) where we enabled support for `%p` for filenames specified in jcmd. 
> 
> With this patch, I propose: 
> - Expanding the utility function `Arguments::copy_expand_pid` to `Arguments::copy_expand_arguments` to deal with `%p` expansions for pid and `%t` expansions for timestamps. 
> - Leveraging the above utility function to enable argument expansion for both heap dump filenames and jcmd output commands. 
> - Though the linked JBS issue only relates to heap dumps generated in case of OOM, I think we can edit it to more broadly support filename expansion to support `%t` for jcmd as well. 
> 
> Testing: 
> - [x] Added test cases pass with all platforms (verified with a GHA job). 
> - [x] Tier 1 passes with GHA. 
> 
> Looking forward to hearing your thoughts!
> 
> Thanks, 
> Sonia

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20568

From amansha at kth.se  Mon Dec 30 14:42:21 2024
From: amansha at kth.se (Aman Sharma)
Date: Mon, 30 Dec 2024 14:42:21 +0000
Subject: Why does jstack not trigger a warning in target JVM >= 21?
Message-ID: <4171b12b29df447d882513ff51a13cd7@kth.se>

Hi all,


I hope this is the correct email thread to ask a question related to JEP 451: Prepare to Disallow the Dynamic Loading of Agents<https://openjdk.org/jeps/451>.


For some context, we at KTH are trying to build a serviceability tool that would monitor dependencies that are running in the target JVM. We looked at jstack for inspiration as it is able to return the stack trace of the target JVM, but we want classes instead and then we can get dependencies as we have annotated each class with dependency information.


While looking at jstack, we noticed that it does not trigger the warning "WARNING: A {Java,JVM TI} agent has been loaded dynamically" when the target JVM is 21. However, when we try to build our own agent using the attach API, we get the warning exactly how it says in the JEP. I initially thought that an exception was made for jstack in the open JDK code but I could find it either here<https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java#L107> or here<https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/hotspot/share/prims/jvmtiAgent.cpp#L521>. Could anyone please tell us why a warning is not shown when jstack is dynamically attaching itself?


Details for reproduction


Source code for reproduction is attached. If you use IntelliJ, you can directy load this project and execute the provided run configurations. First executed 'LongRunning' which will simply suspend the thread for a few minutes and then the 'AgentLoader' will try to attach itself dynamically.


If you don't use IntelliJ, please add '--add-exports jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED --add-modules jdk.jcmd --add-exports jdk.jcmd/sun.tools.jps=ALL-UNNAMED' to your Java compiler and JVM to run the above classes.


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241230/31e418b6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jep451.zip
Type: application/zip
Size: 3547 bytes
Desc: jep451.zip
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241230/31e418b6/jep451-0001.zip>

From ecki at zusammenkunft.net  Mon Dec 30 21:53:31 2024
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 30 Dec 2024 22:53:31 +0100
Subject: Why does jstack not trigger a warning in target JVM >= 21?
In-Reply-To: <4171b12b29df447d882513ff51a13cd7@kth.se>
References: <4171b12b29df447d882513ff51a13cd7@kth.se>
Message-ID: <5DBF994F-3D02-464E-AF62-618975106BAB@hxcore.ol>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241230/1884ab5b/attachment.htm>

From alan.bateman at oracle.com  Tue Dec 31 07:00:57 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Dec 2024 07:00:57 +0000
Subject: Why does jstack not trigger a warning in target JVM >= 21?
In-Reply-To: <4171b12b29df447d882513ff51a13cd7@kth.se>
References: <4171b12b29df447d882513ff51a13cd7@kth.se>
Message-ID: <fcc5e567-0715-4837-91f1-fd2ea3ff3e8b@oracle.com>

On 30/12/2024 14:42, Aman Sharma wrote:
>
> Hi all,
>
>
> I hope this is the correct email thread to ask a question related to 
> JEP 451: Prepare to Disallow the Dynamic Loading of Agents 
> <https://openjdk.org/jeps/451>.
>
>
> For some context, we at KTH are trying to build a serviceability tool 
> that would monitor dependencies that are running in the target JVM. We 
> looked at jstack for inspiration as it is able to return the stack 
> trace of the target JVM, but we want classes instead and then we can 
> get dependencies as we have annotated each class with dependency 
> information.
>
>
> While looking at jstack, we noticed that it does not trigger the 
> warning "WARNING: A {Java,JVM TI} agent has been loaded dynamically" 
> when the target JVM is 21. However, when we try to build our own agent 
> using the attach API, we get the warning exactly how it says in the 
> JEP. I initially thought that an exception was made for jstack in the 
> open JDK code but I could find it either here 
> <https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java#L107> 
> or here 
> <https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/hotspot/share/prims/jvmtiAgent.cpp#L521>. 
> Could anyone please tell us why a warning is not shown when jstack is 
> dynamically attaching itself?
>
>
Attaching to a running VM to run diagnostic commands doesn't trigger a 
warning. The warning is limited to cases where code (in the form of a 
JVMTI agent in a shared library, or a Java agent in an agent JAR file) 
is loaded into a running VM without opt-in on the command line.

It might be that some of of the existing jcmd commands might give you 
inspiration. While most of the diagnostic commands in written in C++, 
there are a number of commands implemented in Java that may be closer to 
what you are looking for.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241231/2d7821d1/attachment-0001.htm>

From amansha at kth.se  Tue Dec 31 13:13:15 2024
From: amansha at kth.se (Aman Sharma)
Date: Tue, 31 Dec 2024 13:13:15 +0000
Subject: Why does jstack not trigger a warning in target JVM >= 21?
In-Reply-To: <fcc5e567-0715-4837-91f1-fd2ea3ff3e8b@oracle.com>
References: <4171b12b29df447d882513ff51a13cd7@kth.se>,
 <fcc5e567-0715-4837-91f1-fd2ea3ff3e8b@oracle.com>
Message-ID: <59f71517e01c480c865c9f9d17941ea2@kth.se>

Dear Bernd,


> You sure you do the same thing?


Was a bit confused, but Alan clarified it. Thanks!


Dear Alan,


> The warning is limited to cases where code (in the form of a JVMTI agent in a shared library, or a Java agent in an agent JAR file) is loaded into a running VM without opt-in on the command line


I was of the opinion that usage of any API in `com.sun.tools.attach`<https://docs.oracle.com/en/java/javase/21/docs/api/jdk.attach/com/sun/tools/attach/package-summary.html> package would trigger this warning, but it is clear to me now when the warning will be triggered. Thank you for your answer!


> , there are a number of commands implemented in Java that may be closer to what you are looking for.


We will take a look, thanks!


Regards,
Aman Sharma

PhD Student
KTH Royal Institute of Technology
School of Electrical Engineering and Computer Science (EECS)
Department of Theoretical Computer Science (TCS)
<http://www.kth.se><https://www.kth.se/profile/amansha><https://www.kth.se/profile/amansha>
<https://www.kth.se/profile/amansha>https://algomaster99.github.io/
________________________________
From: Alan Bateman <alan.bateman at oracle.com>
Sent: Tuesday, December 31, 2024 8:00:57 AM
To: Aman Sharma; serviceability-dev at openjdk.org
Cc: Serena Cofano
Subject: Re: Why does jstack not trigger a warning in target JVM >= 21?

On 30/12/2024 14:42, Aman Sharma wrote:

Hi all,


I hope this is the correct email thread to ask a question related to JEP 451: Prepare to Disallow the Dynamic Loading of Agents<https://openjdk.org/jeps/451>.


For some context, we at KTH are trying to build a serviceability tool that would monitor dependencies that are running in the target JVM. We looked at jstack for inspiration as it is able to return the stack trace of the target JVM, but we want classes instead and then we can get dependencies as we have annotated each class with dependency information.


While looking at jstack, we noticed that it does not trigger the warning "WARNING: A {Java,JVM TI} agent has been loaded dynamically" when the target JVM is 21. However, when we try to build our own agent using the attach API, we get the warning exactly how it says in the JEP. I initially thought that an exception was made for jstack in the open JDK code but I could find it either here<https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java#L107> or here<https://github.com/openjdk/jdk/blob/24c5ff7ba58cb7cf93df07f81484cd8fae60e31e/src/hotspot/share/prims/jvmtiAgent.cpp#L521>. Could anyone please tell us why a warning is not shown when jstack is dynamically attaching itself?

Attaching to a running VM to run diagnostic commands doesn't trigger a warning. The warning is limited to cases where code (in the form of a JVMTI agent in a shared library, or a Java agent in an agent JAR file) is loaded into a running VM without opt-in on the command line.

It might be that some of of the existing jcmd commands might give you inspiration. While most of the diagnostic commands in written in C++, there are a number of commands implemented in Java that may be closer to what you are looking for.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241231/753121ef/attachment.htm>