From duke at openjdk.org  Tue Oct  1 01:18:44 2024
From: duke at openjdk.org (duke)
Date: Tue, 1 Oct 2024 01:18:44 GMT
Subject: RFR: 8334305: Remove all code for  nsk.share.Log verbose mode
In-Reply-To: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
Message-ID: <aFu1GontUcpL6PkOPmEN_PKV5oftCHvqyBHu7JzNwcE=.a89074ba-a76a-4566-a8a0-468960000a1c@github.com>

On Mon, 30 Sep 2024 14:55:33 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Cleaning up nsk.share.Log code after the verbose mode was set always true.
> 
> Tested all the vmTestbase/ tests.

@rsunderbabu 
Your change (at version a346de1ce3387f99bb3f8d63c64b9c6bc1212bcb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21267#issuecomment-2384589800

From rsunderbabu at openjdk.org  Tue Oct  1 01:39:45 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 1 Oct 2024 01:39:45 GMT
Subject: RFR: 8334305: Remove all code for  nsk.share.Log verbose mode
In-Reply-To: <mbMbim2NEzQ1Z-GgAwNfsi_qRf9Qkx8IVezkwi6DUJA=.4e7ad4b6-4639-4f0e-8340-1e4f54f07ef0@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <mbMbim2NEzQ1Z-GgAwNfsi_qRf9Qkx8IVezkwi6DUJA=.4e7ad4b6-4639-4f0e-8340-1e4f54f07ef0@github.com>
Message-ID: <0Ta3dThVeJ0U5IaOnG16uyL6dpoIgszgdUOzqe77Fvg=.bac0890f-a77a-4dd3-9b60-c5c6143d097a@github.com>

On Mon, 30 Sep 2024 21:07:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 287:
> 
>> 285:         if (!verbose()) {
>> 286:             doPrint(message);
>> 287:         }
> 
> Is this method ever called? Is there a CR to remove it (and any references to it)?

These are deprecated methods and are still getting called. The calls need to be replaced with display. I will create a separate CR for this and address because the impact radius of such a change is bigger than this CR.

> test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 342:
> 
>> 340:      * Redirect log to the given <code>stream</code>
>> 341:      * Prints errors summary to current stream, cancel current stream
>> 342:      * and switches to new stream.
> 
> Does it really do all this? It looks to me like it just switches to the new stream. I'm not sure what is meant by "error summary" and cancelling.

marked for deprecation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21267#discussion_r1782010079
PR Review Comment: https://git.openjdk.org/jdk/pull/21267#discussion_r1782010577

From dholmes at openjdk.org  Tue Oct  1 01:44:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 01:44:40 GMT
Subject: RFR: 8334305: Remove all code for  nsk.share.Log verbose mode
In-Reply-To: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
Message-ID: <kkHDhVzeJZgJ774d31ajFgO8gMR5WN9RzQ4bcvR4Gvc=.a3cb09ce-f215-4487-a7fa-0f91f09f799f@github.com>

On Mon, 30 Sep 2024 14:55:33 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Cleaning up nsk.share.Log code after the verbose mode was set always true.
> 
> Tested all the vmTestbase/ tests.

@rsunderbabu  this should wait for the second review by @plummercj  to be completed before it is integrated. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21267#issuecomment-2384614479

From rsunderbabu at openjdk.org  Tue Oct  1 01:52:20 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 1 Oct 2024 01:52:20 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v2]
In-Reply-To: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
Message-ID: <izlkoCqG4I-TdvsJhiwKTiopg6Py6oCQkQ-u_VupCtc=.dbbd487b-5d99-419f-b380-21906d3ead91@github.com>

> Cleaning up nsk.share.Log code after the verbose mode was set always true.
> 
> Tested all the vmTestbase/ tests.

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

  Addressed review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21267/files
  - new: https://git.openjdk.org/jdk/pull/21267/files/a346de1c..097789b2

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

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

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

From rsunderbabu at openjdk.org  Tue Oct  1 01:52:20 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 1 Oct 2024 01:52:20 GMT
Subject: RFR: 8334305: Remove all code for  nsk.share.Log verbose mode
In-Reply-To: <kkHDhVzeJZgJ774d31ajFgO8gMR5WN9RzQ4bcvR4Gvc=.a3cb09ce-f215-4487-a7fa-0f91f09f799f@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <kkHDhVzeJZgJ774d31ajFgO8gMR5WN9RzQ4bcvR4Gvc=.a3cb09ce-f215-4487-a7fa-0f91f09f799f@github.com>
Message-ID: <r9Zhpc7nMtpIkq3oyRkacZtOfHsk9INwtEI2hGRbSFU=.e9f7331d-f121-4386-9b20-cef0916d702b@github.com>

On Tue, 1 Oct 2024 01:42:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @rsunderbabu this should wait for the second review by @plummercj to be completed before it is integrated. Thanks.

Thanks for pointing out David. I missed seeing those comments. I have addressed them now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21267#issuecomment-2384620630

From cjplummer at openjdk.org  Tue Oct  1 04:07:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Oct 2024 04:07:36 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v2]
In-Reply-To: <izlkoCqG4I-TdvsJhiwKTiopg6Py6oCQkQ-u_VupCtc=.dbbd487b-5d99-419f-b380-21906d3ead91@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <izlkoCqG4I-TdvsJhiwKTiopg6Py6oCQkQ-u_VupCtc=.dbbd487b-5d99-419f-b380-21906d3ead91@github.com>
Message-ID: <KaF2d5NW4sKtJpC-GCRvFiGK1tTBR4et12hfbb4w31A=.2e991bbf-63d7-43d9-b259-3faad68fc1f4@github.com>

On Tue, 1 Oct 2024 01:52:20 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 40:

> 38: 
> 39: /**
> 40:  * This class helps to print test-execution trace messages

Missing period.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21267#discussion_r1782080651

From cjplummer at openjdk.org  Tue Oct  1 04:07:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Oct 2024 04:07:37 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v2]
In-Reply-To: <0Ta3dThVeJ0U5IaOnG16uyL6dpoIgszgdUOzqe77Fvg=.bac0890f-a77a-4dd3-9b60-c5c6143d097a@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <mbMbim2NEzQ1Z-GgAwNfsi_qRf9Qkx8IVezkwi6DUJA=.4e7ad4b6-4639-4f0e-8340-1e4f54f07ef0@github.com>
 <0Ta3dThVeJ0U5IaOnG16uyL6dpoIgszgdUOzqe77Fvg=.bac0890f-a77a-4dd3-9b60-c5c6143d097a@github.com>
Message-ID: <X268p6CzxaLECyLNrowk6zxKIksFsKGgYRFr0h_eNLo=.8545725d-9f4c-43e2-a275-8a3b3bd79d34@github.com>

On Tue, 1 Oct 2024 01:35:54 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 287:
>> 
>>> 285:         if (!verbose()) {
>>> 286:             doPrint(message);
>>> 287:         }
>> 
>> Is this method ever called? Is there a CR to remove it (and any references to it)?
>
> These are deprecated methods and are still getting called. The calls need to be replaced with display. I will create a separate CR for this and address because the impact radius of such a change is bigger than this CR.

ok

>> test/hotspot/jtreg/vmTestbase/nsk/share/Log.java line 342:
>> 
>>> 340:      * Redirect log to the given <code>stream</code>
>>> 341:      * Prints errors summary to current stream, cancel current stream
>>> 342:      * and switches to new stream.
>> 
>> Does it really do all this? It looks to me like it just switches to the new stream. I'm not sure what is meant by "error summary" and cancelling.
>
> marked for deprecation.

Ok, but unless it is going to be removed by another CR soon, I think the comments should at least reflect what it currently does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21267#discussion_r1782080971
PR Review Comment: https://git.openjdk.org/jdk/pull/21267#discussion_r1782081564

From rsunderbabu at openjdk.org  Tue Oct  1 06:10:38 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 1 Oct 2024 06:10:38 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v2]
In-Reply-To: <izlkoCqG4I-TdvsJhiwKTiopg6Py6oCQkQ-u_VupCtc=.dbbd487b-5d99-419f-b380-21906d3ead91@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <izlkoCqG4I-TdvsJhiwKTiopg6Py6oCQkQ-u_VupCtc=.dbbd487b-5d99-419f-b380-21906d3ead91@github.com>
Message-ID: <4182tKmfcha4-_wRjzwesK9qFrI8F5HflR45upgCD60=.7dfddadd-5c29-4127-8231-ab5095a9f099@github.com>

On Tue, 1 Oct 2024 01:52:20 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments

JDK-8341302 created for addressing deprecated method usage.

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

PR Comment: https://git.openjdk.org/jdk/pull/21267#issuecomment-2384878446

From rsunderbabu at openjdk.org  Tue Oct  1 07:01:17 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 1 Oct 2024 07:01:17 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v3]
In-Reply-To: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
Message-ID: <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>

> Cleaning up nsk.share.Log code after the verbose mode was set always true.
> 
> Tested all the vmTestbase/ tests.

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

  Addressed review comments part2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21267/files
  - new: https://git.openjdk.org/jdk/pull/21267/files/097789b2..b895705a

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

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

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

From mli at openjdk.org  Tue Oct  1 07:29:41 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 1 Oct 2024 07:29:41 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v3]
In-Reply-To: <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
Message-ID: <Eb2PumX-uXDDdZ1TX7Xw2dek5tFhYu2SeGLoCmZo9I0=.48fc0212-3fc1-442b-98bb-0515fa2d6797@github.com>

On Tue, 1 Oct 2024 07:01:17 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments part2

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21267#pullrequestreview-2339332109

From dholmes at openjdk.org  Tue Oct  1 07:35:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 07:35:55 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v7]
In-Reply-To: <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
Message-ID: <XtY8amlkWTUKZsNCVyrCcpte2x_YyrWLgj5DF6Fy_QA=.121969b7-9d1d-451a-accf-278e0cddadca@github.com>

On Sun, 29 Sep 2024 06:23:34 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl 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 remote-tracking branch 'upstream/master' into 8327114-attach-from-container-to-container
>  - Clarify PID 1 check with comment
>  - Adapt code style
>  - Add test for the elevated privileges case
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable
>  - Reworked attach logic
>  - 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

We are seeing a number of test failures after this was integrated. Failing tests:
- containers/docker/TestJcmdWithSideCar.java
-  com/sun/tools/attach/PermissionTest.java
- 
I will file bugs, but the permission test fails because the new code throws a SecurityException when the SecurityManager is enabled:

Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/proc/self/ns/mnt" "readlink")
	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
	at java.base/java.security.AccessController.checkPermission(AccessController.java:1085)
	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
	at java.base/sun.nio.fs.UnixFileSystemProvider.readSymbolicLink(UnixFileSystemProvider.java:554)
	at java.base/java.nio.file.Files.readSymbolicLink(Files.java:1474)
	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<clinit>(VirtualMachineImpl.java:66)

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2385009640

From aboldtch at openjdk.org  Tue Oct  1 08:05:47 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 08:05:47 GMT
Subject: RFR: 8341168: Cleanup dead code after JDK-8322630 [v2]
In-Reply-To: <ybP1ps8O7SmKbAyh20vTql4HjIIIKGE3JGrmht9vXeY=.79779c55-f7a5-4e1b-bf1e-a286203efc9d@github.com>
References: <boNfv6TaX_UapkKp_7cZVfy68m6XSIuLVM6udDDAMD8=.27471cdf-18c6-4ecd-9018-85aa1f6db166@github.com>
 <ybP1ps8O7SmKbAyh20vTql4HjIIIKGE3JGrmht9vXeY=.79779c55-f7a5-4e1b-bf1e-a286203efc9d@github.com>
Message-ID: <IQllmYG8y7VB_GaUqBsc4EX06-jHEykY2mXMU5uQ2rE=.3d5252b8-3e67-4413-8556-305c8172b823@github.com>

On Mon, 30 Sep 2024 08:15:51 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed the the concept of ICStubs, InlineCache buffers and related safepoints.
>> 
>> There are a handfull of references and auxiliary constructs still in the code, I propose we clean these out.
>> 
>> This removes the unused:
>>  * Experimental `InlineCacheBufferSize` option
>>  * `InlineCacheBuffer_lock` mutex
>>  * `Thread::_missed_ic_stub_refill_verifier` field
>>  * `VM_ICBufferFull` VM operation
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add newline

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21255#issuecomment-2385063512

From aboldtch at openjdk.org  Tue Oct  1 08:05:48 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 1 Oct 2024 08:05:48 GMT
Subject: Integrated: 8341168: Cleanup dead code after JDK-8322630
In-Reply-To: <boNfv6TaX_UapkKp_7cZVfy68m6XSIuLVM6udDDAMD8=.27471cdf-18c6-4ecd-9018-85aa1f6db166@github.com>
References: <boNfv6TaX_UapkKp_7cZVfy68m6XSIuLVM6udDDAMD8=.27471cdf-18c6-4ecd-9018-85aa1f6db166@github.com>
Message-ID: <a8lCr6eFzCCRx2nlLFPYl-MeU52x_YEXAPJKn4T3CIg=.f260df3b-5231-4be5-a182-c97b3cf1b360@github.com>

On Mon, 30 Sep 2024 07:39:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed the the concept of ICStubs, InlineCache buffers and related safepoints.
> 
> There are a handfull of references and auxiliary constructs still in the code, I propose we clean these out.
> 
> This removes the unused:
>  * Experimental `InlineCacheBufferSize` option
>  * `InlineCacheBuffer_lock` mutex
>  * `Thread::_missed_ic_stub_refill_verifier` field
>  * `VM_ICBufferFull` VM operation

This pull request has now been integrated.

Changeset: ad5ffccf
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad5ffccffa89359dac6ad44b9e43242e5bf3e398
Stats:     38 lines in 10 files changed: 0 ins; 34 del; 4 mod

8341168: Cleanup dead code after JDK-8322630

Reviewed-by: stefank, tschatzl, mli, shade

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

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

From kevinw at openjdk.org  Tue Oct  1 08:53:40 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Oct 2024 08:53:40 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied
In-Reply-To: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
Message-ID: <Ri9ALBN7P447e1ETMq9e_rjvjBNcO6l4GsGgoFShYQ0=.1a189dd4-97ab-42d6-9d30-153adf36f63a@github.com>

On Mon, 30 Sep 2024 16:11:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
> So this PR add `readlink` permission to make this test work normally.
> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

Yes, agreed the readlink fixes the problem, thanks, looks good.  Agree that joining the comment would be good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21269#pullrequestreview-2339556019

From sgehwolf at openjdk.org  Tue Oct  1 09:09:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 09:09:45 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v7]
In-Reply-To: <XtY8amlkWTUKZsNCVyrCcpte2x_YyrWLgj5DF6Fy_QA=.121969b7-9d1d-451a-accf-278e0cddadca@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
 <XtY8amlkWTUKZsNCVyrCcpte2x_YyrWLgj5DF6Fy_QA=.121969b7-9d1d-451a-accf-278e0cddadca@github.com>
Message-ID: <eBTnb5iIP3xp7ittyj8Y7dPARX3oVJrCGIm36ajgnPc=.75d580ea-e744-4059-98ce-9d4fa8e9c957@github.com>

On Tue, 1 Oct 2024 07:33:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We are seeing a number of test failures after this was integrated. Failing tests:
> 
>     * containers/docker/TestJcmdWithSideCar.java

What's the failure?

>     * com/sun/tools/attach/PermissionTest.java
> 
> I will file bugs, but the permission test fails because the new code throws a SecurityException when the SecurityManager is enabled:
> 
> ```
> Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/proc/self/ns/mnt" "readlink")
> 	at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:488)
> 	at java.base/java.security.AccessController.checkPermission(AccessController.java:1085)
> 	at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:411)
> 	at java.base/sun.nio.fs.UnixFileSystemProvider.readSymbolicLink(UnixFileSystemProvider.java:554)
> 	at java.base/java.nio.file.Files.readSymbolicLink(Files.java:1474)
> 	at jdk.attach/sun.tools.attach.VirtualMachineImpl.<clinit>(VirtualMachineImpl.java:66)
> ```

This is handled here: https://git.openjdk.org/jdk/pull/21269

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2385229823

From duke at openjdk.org  Tue Oct  1 09:32:52 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 1 Oct 2024 09:32:52 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v7]
In-Reply-To: <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
Message-ID: <g_kgge720Ta0x0Wa8XKlHaCVbyHaLsvUQEMRKzLFn-k=.5d3d37f4-7acf-4e9a-b224-9acd98504afd@github.com>

On Sun, 29 Sep 2024 06:23:34 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl 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 remote-tracking branch 'upstream/master' into 8327114-attach-from-container-to-container
>  - Clarify PID 1 check with comment
>  - Adapt code style
>  - Add test for the elevated privileges case
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable
>  - Reworked attach logic
>  - 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Sorry for this. I'm happy to look into the `com/sun/tools/attach/PermissionTest.java` if you can provide more details about the failure (and the environment it fails in).

Is this something that should have failed in GHA checks too?

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2385274397
PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2385279008

From duke at openjdk.org  Tue Oct  1 09:35:37 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 1 Oct 2024 09:35:37 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114
In-Reply-To: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
Message-ID: <fOlAm7tnXM1GX8Fx_wlL3heXJXogdOc3vz_LUUA0V6I=.2c2f3eea-1577-401e-b7a0-ac23a0e8dcdc@github.com>

On Mon, 30 Sep 2024 16:11:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
> So this PR add `readlink` permission to make this test work normally.
> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

Thanks for taking care of fixing this @sendaoYan!

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

Marked as reviewed by slovdahl at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/21269#pullrequestreview-2339663336

From sgehwolf at openjdk.org  Tue Oct  1 10:08:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 10:08:44 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v7]
In-Reply-To: <g_kgge720Ta0x0Wa8XKlHaCVbyHaLsvUQEMRKzLFn-k=.5d3d37f4-7acf-4e9a-b224-9acd98504afd@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
 <g_kgge720Ta0x0Wa8XKlHaCVbyHaLsvUQEMRKzLFn-k=.5d3d37f4-7acf-4e9a-b224-9acd98504afd@github.com>
Message-ID: <ViidOi7d_Ohf_dpq5890lD581o_Qy8poJBGACY_OxRY=.fa6ee1f3-5865-4af2-bff4-7b75aa39f053@github.com>

On Tue, 1 Oct 2024 09:29:20 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> Is this something that should have failed in GHA checks too?

No. Only tier1 tests run in GHA.

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2385367053

From zzambers at openjdk.org  Tue Oct  1 13:28:44 2024
From: zzambers at openjdk.org (Zdenek Zambersky)
Date: Tue, 1 Oct 2024 13:28:44 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v9]
In-Reply-To: <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <NHU4AA8r7Ws8FYvfLDQ1XPxYBqGJS_PPG_dLmsEw0Eo=.e4d3e2d2-0d07-4593-a8bc-7602fbd0ff59@github.com>
Message-ID: <ZffKwrV_XFwTxMs3BPue_-_jGbR1kDUJE_QmwXK44ks=.ce5a72fb-2452-426c-aa98-00bd84526e06@github.com>

On Mon, 30 Sep 2024 12:03:14 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 34 commits:
> 
>  - 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
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/475b8943...92426dbf

I can confirm that `jdk/internal/platform` tests now pass for me on RHEL-9 (cgroup v2)

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2385851987

From syan at openjdk.org  Tue Oct  1 15:38:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Oct 2024 15:38:56 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <JVFspZPz_kaVpQVFlzUWJ5PMzJreb0JZDpbtbWfD9eM=.dd50c2dd-4ee7-4223-bd95-a8d528e2c14b@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <JVFspZPz_kaVpQVFlzUWJ5PMzJreb0JZDpbtbWfD9eM=.dd50c2dd-4ee7-4223-bd95-a8d528e2c14b@github.com>
Message-ID: <UEcGi0wEgFLwL4Hv6qFvkL2ESknTcnM-P3fedPCPyTE=.5844a23f-5732-402c-a424-d695b0c3e307@github.com>

On Mon, 30 Sep 2024 17:05:08 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge two comments enclosed with /* ... */ on two lines
>
> test/jdk/com/sun/tools/attach/java.policy.allow line 17:
> 
>> 15: 
>> 16:     /* to read configuration file in META-INF/services, and write/delete .attach_pid<pid> */
>> 17:     /* to read symbol link in /proc/self/ns/mnt */
> 
> Suggestion:
> 
>     /* to read symbolic link of /proc/self/ns/mnt */
> 
> 
> Perhaps merge the two comments enclosed with `/* ... */` on two lines?

Okey, the two comments has been merged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21269#discussion_r1783093102

From syan at openjdk.org  Tue Oct  1 15:38:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Oct 2024 15:38:56 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
Message-ID: <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>

> Hi all,
> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
> So this PR add `readlink` permission to make this test work normally.
> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

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

  merge two comments enclosed with /* ... */ on two lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21269/files
  - new: https://git.openjdk.org/jdk/pull/21269/files/f241371e..015d17cb

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

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

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

From rkennke at openjdk.org  Tue Oct  1 15:48:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 1 Oct 2024 15:48:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
 <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
 <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
Message-ID: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>

On Mon, 30 Sep 2024 12:38:03 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:

I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2386370790

From sgehwolf at openjdk.org  Tue Oct  1 16:21:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 16:21:44 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
Message-ID: <fOYGsE-U8GDuKUJfyf-PXCi3gX-5oljRq1CgGDZqCaY=.dd97101c-94fa-4792-bd25-5e72241baa98@github.com>

On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge two comments enclosed with /* ... */ on two lines

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21269#pullrequestreview-2340853189

From sgehwolf at openjdk.org  Tue Oct  1 16:26:52 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 16:26:52 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java fails
 after JDK-8327114
Message-ID: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>

The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):

1. Shared volumes between attachee and attacher and shared pid namespace
2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
3. Shared pid namespace between attachee and attacher only
4. Shared pid namespace between attachee and attacher, both running with elevated privileges

The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).

While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:


Passed: containers/docker/TestJcmdWithSideCar.java
  build: 2.08 seconds
  compile: 2.068 seconds
  build: 4.842 seconds
  compile: 4.841 seconds
  driver: 70.776 seconds
Test results: passed: 1


I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:


Passed: containers/docker/TestJcmdWithSideCar.java
  build: 2.169 seconds
  compile: 2.157 seconds
  build: 4.964 seconds
  compile: 4.963 seconds
  driver: 22.928 seconds
Test results: passed: 1


The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f

Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!

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

Commit messages:
 - Improve runtime of test
 - 8341310: Test containers/docker/TestJcmdWithSideCar.java fails after JDK-8327114

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

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

From sgehwolf at openjdk.org  Tue Oct  1 16:26:52 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 16:26:52 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <ZND-cslaoxC_yP_egRfXRzr8IZJbs_SZFsRwsqFBj24=.4487cc09-fd16-436e-a408-8de000bf894c@github.com>

On Tue, 1 Oct 2024 16:16:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.08 seconds
>   compile: 2.068 seconds
>   build: 4.842 seconds
>   compile: 4.841 seconds
>   driver: 70.776 seconds
> Test results: passed: 1
> 
> 
> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.169 seconds
>   compile: 2.157 seconds
>   build: 4.964 seconds
>   compile: 4.963 seconds
>   driver: 22.928 seconds
> Test results: passed: 1
> 
> 
> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue?...

PTAL @slovdahl Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2386454865

From kevinw at openjdk.org  Tue Oct  1 16:58:33 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Oct 2024 16:58:33 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <zpVOtBu9QdTgXj6eWjDcJuUPrfJvouvN_P4m7UDJd7E=.1affce5a-634f-4039-b93a-b540839b7c91@github.com>

On Tue, 1 Oct 2024 16:16:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.08 seconds
>   compile: 2.068 seconds
>   build: 4.842 seconds
>   compile: 4.841 seconds
>   driver: 70.776 seconds
> Test results: passed: 1
> 
> 
> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.169 seconds
>   compile: 2.157 seconds
>   build: 4.964 seconds
>   compile: 4.963 seconds
>   driver: 22.928 seconds
> Test results: passed: 1
> 
> 
> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue?...

Thanks for clarifying the different testing combinations and the pointer to the missing one for follow up in JDK-8341349.
I can check our testing with this change...

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2386516815

From cjplummer at openjdk.org  Tue Oct  1 17:27:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Oct 2024 17:27:42 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v3]
In-Reply-To: <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
Message-ID: <p4U4PHeBnXiyr4kvH7_QBbqrr_d2939vV57u13XM6WI=.2fdb5470-9afe-42d0-9e3f-7e143cbdd041@github.com>

On Tue, 1 Oct 2024 07:01:17 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments part2

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21267#pullrequestreview-2340977043

From sgehwolf at openjdk.org  Tue Oct  1 18:20:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Oct 2024 18:20:36 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <BJkCXW4YBnxFPOKkb6NBVSq2dtrvPls_bL5cELDFzvA=.31409cac-365c-454c-891a-ffabddff0abe@github.com>

On Tue, 1 Oct 2024 16:16:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.08 seconds
>   compile: 2.068 seconds
>   build: 4.842 seconds
>   compile: 4.841 seconds
>   driver: 70.776 seconds
> Test results: passed: 1
> 
> 
> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.169 seconds
>   compile: 2.157 seconds
>   build: 4.964 seconds
>   compile: 4.963 seconds
>   driver: 22.928 seconds
> Test results: passed: 1
> 
> 
> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue?...

Thanks, Kevin.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2386669079

From amenkov at openjdk.org  Tue Oct  1 18:53:41 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Oct 2024 18:53:41 GMT
Subject: Integrated: 8341060: Cleanup statics in HeapDumper
In-Reply-To: <ZHizciXjozLmzb3HUsIIC9nTS3uvSauJVuSHw3TV-FI=.8736f23b-dbe2-4852-ab6c-506208feabef@github.com>
References: <ZHizciXjozLmzb3HUsIIC9nTS3uvSauJVuSHw3TV-FI=.8736f23b-dbe2-4852-ab6c-506208feabef@github.com>
Message-ID: <b_FXevEE77wtAQNj3Eu9cyChg4D5zFR_tNdhwZHqKOw=.d73edf99-7521-4c75-b9e6-7606253c9dbc@github.com>

On Fri, 27 Sep 2024 01:28:18 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix cleans up static variables/methods in HeapDumper.
> See jira for details.
> 
> Testing:
>   heap dump-related tests (test/hotspot/jtreg/serviceability, test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndHeapDump.java, test/hotspot/jtreg/runtime/ErrorHandling, test/hotspot/jtreg/gc/epsilon, test/jdk/sun/tools/jhsdb, test/jdk/sun/tools/jmap, test/jdk/com/sun/management/HotSpotDiagnosticMXBean)

This pull request has now been integrated.

Changeset: 03149735
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/03149735e59b7d1d409a6e29ee05ae0537e03d53
Stats:     96 lines in 1 file changed: 32 ins; 59 del; 5 mod

8341060: Cleanup statics in HeapDumper

Reviewed-by: shade, sspitsyn

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

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

From duke at openjdk.org  Tue Oct  1 20:12:50 2024
From: duke at openjdk.org (Larry Cable)
Date: Tue, 1 Oct 2024 20:12:50 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v7]
In-Reply-To: <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
References: <BHh0pbgaSrN8NfAgiMcoz7tCIfuccF_AOy4u3SH3nbk=.12863dc7-fba2-40ba-af2a-da67a9754d37@github.com>
 <o22Yt9swYmpUL5TZBDR8ga3mlZpiuz1lVRf8jBpLu9I=.fa8aaddc-cc71-479c-ad27-2ccddda1f2fd@github.com>
Message-ID: <apyGjZmBlzyT_2-kmWiriFUi3yb3WaYsYHRPh-3q_ic=.8059a3fd-49bc-4baa-9b90-f99bc6665cbe@github.com>

On Sun, 29 Sep 2024 06:23:34 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)
>
> Sebastian L?vdahl 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 remote-tracking branch 'upstream/master' into 8327114-attach-from-container-to-container
>  - Clarify PID 1 check with comment
>  - Adapt code style
>  - Add test for the elevated privileges case
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable
>  - Reworked attach logic
>  - 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

I believe we need to wrap the readlink() in an AccessController.doPrivileged() block ... something like this:

`
try {
  targetMountNS = AccessController.doPrivileged(
    (PrivilegedExceptionAction<Optional<Path>>) () -> Optional.ofNullable(Files.readSymbolicLink(procPidPath.resolve(NS_MNT)))
  );
} catch (PrivilegedActionException _) {
// ...
}
`

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

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2386973409

From dholmes at openjdk.org  Tue Oct  1 21:16:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Oct 2024 21:16:37 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
Message-ID: <2LRPLbNHs_V1N6eYyblqBmIrVhu_7m5_BUaiA51z4b4=.d6b2c139-6239-4cc4-bfde-b0f3328a2a5a@github.com>

On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge two comments enclosed with /* ... */ on two lines

test/jdk/com/sun/tools/attach/java.policy.allow line 17:

> 15: 
> 16:     /* to read configuration file in META-INF/services, write/delete .attach_pid<pid>, 
> 17:     and read symbolic link of /proc/self/ns/mnt */

Suggestion:

    /* 
     * To read configuration file in META-INF/services, write/delete .attach_pid<pid>, 
     * and read symbolic link of /proc/self/ns/mnt.
     */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21269#discussion_r1783539848

From cjplummer at openjdk.org  Tue Oct  1 22:03:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Oct 2024 22:03:47 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
Message-ID: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>

The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.

char* translateThreadState(jint flags);
char* getThreadName(jthread thread);
char* getMethodName(jmethodID method);
void printStackTrace(jthread thread);
void printThreadInfo(jthread thread);

I made use of them while working on a couple of recent bugs and found them very useful. 

Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.

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

Commit messages:
 - Add some useful debugging apis

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

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

From duke at openjdk.org  Wed Oct  2 00:52:38 2024
From: duke at openjdk.org (duke)
Date: Wed, 2 Oct 2024 00:52:38 GMT
Subject: RFR: 8334305: Remove all code for nsk.share.Log verbose mode [v3]
In-Reply-To: <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
 <u1e84dUknroXHqtIex4wOmnWIO9zJ12sZDPsLYSRWrc=.660173bb-6974-4026-8b26-57fe82923501@github.com>
Message-ID: <ID_oaX6Zz0vrvgUlLS9_71GLtRpWbREmGolHarRQatU=.9e26ea18-2f3c-43f8-8347-8751990d0190@github.com>

On Tue, 1 Oct 2024 07:01:17 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Cleaning up nsk.share.Log code after the verbose mode was set always true.
>> 
>> Tested all the vmTestbase/ tests.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments part2

@rsunderbabu 
Your change (at version b895705afaae6af7a3c6b3f38e92df737afbeb94) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21267#issuecomment-2387372435

From amenkov at openjdk.org  Wed Oct  2 01:24:42 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 2 Oct 2024 01:24:42 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
In-Reply-To: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
Message-ID: <gwn2S8o_War2deTxnTPuaIYVNpJujhIvcNISsskNPrw=.e0fbbefd-d730-41d1-b728-02bb7b54a43a@github.com>

On Tue, 1 Oct 2024 21:58:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
> 
> char* translateThreadState(jint flags);
> char* getThreadName(jthread thread);
> char* getMethodName(jmethodID method);
> void printStackTrace(jthread thread);
> void printThreadInfo(jthread thread);
> 
> I made use of them while working on a couple of recent bugs and found them very useful. 
> 
> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.

src/jdk.jdwp.agent/share/native/libjdwp/util.c line 1715:

> 1713:     strcpy(tstate, str);
> 1714: 
> 1715:   return tstate;

Suggestion:

    return tstate;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21299#discussion_r1783735671

From cjplummer at openjdk.org  Wed Oct  2 02:20:48 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 2 Oct 2024 02:20:48 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
 [v2]
In-Reply-To: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
Message-ID: <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>

> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
> 
> char* translateThreadState(jint flags);
> char* getThreadName(jthread thread);
> char* getMethodName(jmethodID method);
> void printStackTrace(jthread thread);
> void printThreadInfo(jthread thread);
> 
> I made use of them while working on a couple of recent bugs and found them very useful. 
> 
> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.

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

  Fix indent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21299/files
  - new: https://git.openjdk.org/jdk/pull/21299/files/cbc7cb4f..d9b498bf

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

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

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

From dholmes at openjdk.org  Wed Oct  2 02:37:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Oct 2024 02:37:41 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v7]
In-Reply-To: <HuNnBI2gY1DFppqk5yk5A4VZeL5blHpQTUsYs1E20wo=.7484d4f3-45f2-4c44-8006-410490d40297@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <HuNnBI2gY1DFppqk5yk5A4VZeL5blHpQTUsYs1E20wo=.7484d4f3-45f2-4c44-8006-410490d40297@github.com>
Message-ID: <2o8-FUnnVtdpIeoyrvpeBDxee-K252v3ewtZ2gphvWU=.879c4ec1-abca-42ff-9c98-1015c47072aa@github.com>

On Thu, 26 Sep 2024 12:29:14 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename lock and mutex locker. Add back ThreadCritical when protecting mtChunk.

Okay I am happy with this now. Thanks.

If I heard correctly Thomas is on vacation this month so you may need to proceed with a different second review and follow up when he gets back if there are any problems. I will be on vacation after Friday for 10 days.

src/hotspot/share/utilities/vmError.cpp line 723:

> 721:     // Avoid reentrancy due to mallocs in detailed mode.
> 722:     MemTracker::reduce_tracking_to_summary();
> 723:     // Manually unlock if already holding lock when upon entering error reporting.

Suggestion:

    // Manually unlock if already holding lock upon entering error reporting.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20852#pullrequestreview-2341807048
PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1783770844

From rcastanedalo at openjdk.org  Wed Oct  2 08:29:55 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 2 Oct 2024 08:29:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
 <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
 <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
 <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <ES5Lj2Kg_a8L48WTpysLoDGS8TMHLMTbscJd3QVnAXA=.3eff8632-c747-40d1-a956-342cc45baca4@github.com>

On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> > test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
> 
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?

I don't think so, due to a [limitation in the IR framework precondition language](https://bugs.openjdk.org/browse/JDK-8294279): `UseCompactObjectHeaders` can only appear within a ["flag precondition"](https://github.com/openjdk/jdk/blob/efe3573b9b4ecec0630fdc1c61c765713a5b68e6/test/hotspot/jtreg/compiler/lib/ir_framework/IR.java#L109) whereas `UseSSE>3` needs to be expressed as a ["CPU feature precondition"](https://github.com/openjdk/jdk/blob/efe3573b9b4ecec0630fdc1c61c765713a5b68e6/test/hotspot/jtreg/compiler/lib/ir_framework/IR.java#L137C14-L137C31) for portability (`UseSSE` is not defined for aarch64), and these two cannot be combined with logical operators.

I suggest to disable the IR checks of the failing tests using `applyIf = {"UseCompactObjectHeaders", "false"}` as you did for other similar tests (e.g. `TestMulAddS2I.java`), and document it in [JDK-8340010](https://bugs.openjdk.org/browse/JDK-8340010). Maybe also comment in the tests that the failure happens only with `-XX:UseSSE<=3`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2387906401

From duke at openjdk.org  Wed Oct  2 10:25:34 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 2 Oct 2024 10:25:34 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <ZND-cslaoxC_yP_egRfXRzr8IZJbs_SZFsRwsqFBj24=.4487cc09-fd16-436e-a408-8de000bf894c@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <ZND-cslaoxC_yP_egRfXRzr8IZJbs_SZFsRwsqFBj24=.4487cc09-fd16-436e-a408-8de000bf894c@github.com>
Message-ID: <XvrBkMP_s5mLBS3Qy6EfjAJbN5uOsuv6ZdjgBXI3ut8=.1e2e86ee-d87b-4745-8fa4-20bb5aa9a11b@github.com>

On Tue, 1 Oct 2024 16:23:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> PTAL @slovdahl Thanks!

@jerboaa Thanks a lot for the thorough investigation here!

I was also able to reproduce the failure locally on my Ubuntu 24.04 using `podman` (that runs containers as a regular user):


sudo apt install podman
make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=podman"

...

STDERR:
java.lang.RuntimeException: ACCESS_TMP_VIA_PROC_ROOT: Could not find specified process
	at TestJcmdWithSideCar.testCase01(TestJcmdWithSideCar.java:138)
	at TestJcmdWithSideCar.main(TestJcmdWithSideCar.java:111)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)

...

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
>>                                                       1     0     1     0 <<
==============================


Whereas with `docker` (that runs containers as `root` by default) the test passes:


make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
                                                         1     1     0     0   
==============================


With `podman` and the changes in this PR, the test works again.

> While at it, I've discovered that the EventGeneratorLoop running container always runs for a fixed time: 30 seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run 60 seconds.

Thanks for trying to improve this too, it was quite annoying to have to wait so long for each test run.. ? 

However, when I'm running the test with `docker` with the changes from this PR (`make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"`) I get a new failure: [docker-failure.log](https://github.com/user-attachments/files/17227971/docker-failure.log). If I revert the test runtime optimization (and keep the disabling part) the test works with `docker` again.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2388301598

From rsunderbabu at openjdk.org  Wed Oct  2 10:50:39 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 2 Oct 2024 10:50:39 GMT
Subject: Integrated: 8334305: Remove all code for  nsk.share.Log verbose mode
In-Reply-To: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
References: <I0TFS3Y_mNELeYwsDsDsOuv6NF1FWm_CC22m43UzfgA=.44627e22-25b0-4c68-966b-52cd534fd641@github.com>
Message-ID: <xWAMhyYpWbYYnwYMlhxhIqTYIXGEWx-h5Rs1MQ3L-BM=.287dc032-959d-4228-8236-8ad6493ad346@github.com>

On Mon, 30 Sep 2024 14:55:33 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Cleaning up nsk.share.Log code after the verbose mode was set always true.
> 
> Tested all the vmTestbase/ tests.

This pull request has now been integrated.

Changeset: 855c8a7d
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/855c8a7def21025bc2fc47594f7285a55924c213
Stats:     130 lines in 13 files changed: 0 ins; 100 del; 30 mod

8334305: Remove all code for  nsk.share.Log verbose mode

Reviewed-by: mli, cjplummer, lmesnik

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

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

From sgehwolf at openjdk.org  Wed Oct  2 12:08:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 12:08:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <XvrBkMP_s5mLBS3Qy6EfjAJbN5uOsuv6ZdjgBXI3ut8=.1e2e86ee-d87b-4745-8fa4-20bb5aa9a11b@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <ZND-cslaoxC_yP_egRfXRzr8IZJbs_SZFsRwsqFBj24=.4487cc09-fd16-436e-a408-8de000bf894c@github.com>
 <XvrBkMP_s5mLBS3Qy6EfjAJbN5uOsuv6ZdjgBXI3ut8=.1e2e86ee-d87b-4745-8fa4-20bb5aa9a11b@github.com>
Message-ID: <yRAug416JZ_JpDJxZqvyWWBkOy2wrP4F0o7TqWMr0e8=.1401ee86-3dc4-472d-9e87-27082beac81d@github.com>

On Wed, 2 Oct 2024 10:23:05 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> However, when I'm running the test with `docker` with the changes from this PR (`make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"`) I get a new failure: [docker-failure.log](https://github.com/user-attachments/files/17227971/docker-failure.log). If I revert the test runtime optimization (and keep the disabling part) the test works with `docker` again.

Thanks. Fails with:


[main-container-process] docker: Error response from daemon: Conflict. The container name "/test-container-main" is already in use by container "258e8ebbbac586ffcc6a7703bcb977bd7b4c203f4badb2ab08e1651ee546c1d6". You have to remove (or rename) that container to be able to reuse that name.
[main-container-process] See 'docker run --help'.
java.lang.RuntimeException: Timed out while waiting for main() to start
	at TestJcmdWithSideCar$MainContainer.waitForMainMethodStart(TestJcmdWithSideCar.java:285)
	at TestJcmdWithSideCar.main(TestJcmdWithSideCar.java:110)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)


We'll have to do `docker rm -i /test-container-main` before we start a new one. I'll fix that later today.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2388475781

From duke at openjdk.org  Wed Oct  2 13:28:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 2 Oct 2024 13:28:13 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
Message-ID: <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>

> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
> 
> Testing:
> - 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/20852/files
  - new: https://git.openjdk.org/jdk/pull/20852/files/88e075d1..7ed996e2

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

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

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

From duke at openjdk.org  Wed Oct  2 13:28:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 2 Oct 2024 13:28:13 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v7]
In-Reply-To: <2o8-FUnnVtdpIeoyrvpeBDxee-K252v3ewtZ2gphvWU=.879c4ec1-abca-42ff-9c98-1015c47072aa@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <HuNnBI2gY1DFppqk5yk5A4VZeL5blHpQTUsYs1E20wo=.7484d4f3-45f2-4c44-8006-410490d40297@github.com>
 <2o8-FUnnVtdpIeoyrvpeBDxee-K252v3ewtZ2gphvWU=.879c4ec1-abca-42ff-9c98-1015c47072aa@github.com>
Message-ID: <Sv0MlaiT0PKIjMK2GDwL8OHpEaSAzX0O-heUBftlhu0=.b3af87ca-f3bd-4964-ab0a-80c270d4566e@github.com>

On Wed, 2 Oct 2024 02:34:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay I am happy with this now. Thanks.

Thank you for the review!

> If I heard correctly Thomas is on vacation this month so you may need to proceed with a different second review and follow up when he gets back if there are any problems. I will be on vacation after Friday for 10 days.

Okay got it! Thanks for letting me know.

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2388637467

From rkennke at openjdk.org  Wed Oct  2 15:37:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 2 Oct 2024 15:37:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v29]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
   
   This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
 - Simplify object init code in interpreter
 - Disable some vectorization tests that fail with +UCOH and UseSSE<=3

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/059b1573..aea8f00c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=27-28

  Stats: 47 lines in 6 files changed: 18 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From syan at openjdk.org  Wed Oct  2 15:44:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 15:44:58 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v3]
In-Reply-To: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
Message-ID: <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>

> Hi all,
> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
> So this PR add `readlink` permission to make this test work normally.
> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

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

  make the comment of java.io.FilePermission look more elegant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21269/files
  - new: https://git.openjdk.org/jdk/pull/21269/files/015d17cb..99d6d640

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

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

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

From dcubed at openjdk.org  Wed Oct  2 15:44:58 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 2 Oct 2024 15:44:58 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
Message-ID: <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>

On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge two comments enclosed with /* ... */ on two lines

@sendaoYan - This failure is quite noisy in the Oracle CI. We see
many failures in Tier[567]. When will you be integrating your fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2388992950

From syan at openjdk.org  Wed Oct  2 15:44:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 15:44:58 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
 <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
Message-ID: <hcy1W34MfwU3WkXRQjs4Bv8YCyZsjYwZRjuX1kDQeZA=.5f7b9354-226e-4576-bfff-808d24194212@github.com>

On Wed, 2 Oct 2024 15:36:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @sendaoYan - This failure is quite noisy in the Oracle CI. We see many failures in Tier[567]. When will you be integrating your fix?

Sorry, these days are statutory holidays in China, so my PR processing is quite slow. I will integrate this PR as soon as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2389001329

From syan at openjdk.org  Wed Oct  2 15:44:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 15:44:58 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
Message-ID: <tAU_25CwoxyrO_s7fU1zVx_OYdDol6H04gYGq4uPEZ8=.0f0c7763-3e95-493b-a8f3-d018d10faeeb@github.com>

On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge two comments enclosed with /* ... */ on two lines

The comment has been changed according the latest review, can anyone review again.

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

PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2389005889

From syan at openjdk.org  Wed Oct  2 15:44:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 15:44:58 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <2LRPLbNHs_V1N6eYyblqBmIrVhu_7m5_BUaiA51z4b4=.d6b2c139-6239-4cc4-bfde-b0f3328a2a5a@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
 <2LRPLbNHs_V1N6eYyblqBmIrVhu_7m5_BUaiA51z4b4=.d6b2c139-6239-4cc4-bfde-b0f3328a2a5a@github.com>
Message-ID: <GcFbYq0V4NHpPSrXmOG_37ahsbD7xj28pP4GNSoanNg=.3d12bfb5-3d48-4509-93c6-27bf79916d4b@github.com>

On Tue, 1 Oct 2024 21:13:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge two comments enclosed with /* ... */ on two lines
>
> test/jdk/com/sun/tools/attach/java.policy.allow line 17:
> 
>> 15: 
>> 16:     /* to read configuration file in META-INF/services, write/delete .attach_pid<pid>, 
>> 17:     and read symbolic link of /proc/self/ns/mnt */
> 
> Suggestion:
> 
>     /* 
>      * To read configuration file in META-INF/services, write/delete .attach_pid<pid>, 
>      * and read symbolic link of /proc/self/ns/mnt.
>      */

Thanks for the review. The comment has been changed according your advice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21269#discussion_r1784795554

From kevinw at openjdk.org  Wed Oct  2 16:01:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Oct 2024 16:01:37 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v3]
In-Reply-To: <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
Message-ID: <1quw7O2R2boEfL4l_aNf4td-s3jXHprrbTt3rikUY14=.a858e530-c8c9-4519-9ae9-972d7abc7cdc@github.com>

On Wed, 2 Oct 2024 15:44:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the comment of java.io.FilePermission look more elegant

Looks good, thanks.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21269#pullrequestreview-2343401410

From syan at openjdk.org  Wed Oct  2 16:09:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 16:09:40 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v3]
In-Reply-To: <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
Message-ID: <JWSA5ItXXWSUNyL63cilYeq33LFwNQ-EHVGDsCTAdEw=.a5446d5a-5efa-4efe-b4cc-6211a7a29ffe@github.com>

On Wed, 2 Oct 2024 15:44:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the comment of java.io.FilePermission look more elegant

The latest commit only change the comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2389056092

From syan at openjdk.org  Wed Oct  2 16:09:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 2 Oct 2024 16:09:41 GMT
Subject: Integrated: 8341246: Test com/sun/tools/attach/PermissionTest.java
 fails access denied after JDK-8327114
In-Reply-To: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
Message-ID: <B8ZM8uScVy-fqyd86tqBLHzs8pUvIdgCXIvasORuwYM=.0d5f9b83-1dae-414a-a9a5-0c45cf7164f0@github.com>

On Mon, 30 Sep 2024 16:11:27 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
> So this PR add `readlink` permission to make this test work normally.
> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.

This pull request has now been integrated.

Changeset: 76283dd2
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76283dd2701ca4ad5c1c99a66f3e8e3d0fe55d44
Stats:     7 lines in 1 file changed: 3 ins; 2 del; 2 mod

8341246: Test com/sun/tools/attach/PermissionTest.java fails access denied after JDK-8327114

Reviewed-by: kevinw, sgehwolf

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

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

From sgehwolf at openjdk.org  Wed Oct  2 16:50:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 16:50:05 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.08 seconds
>   compile: 2.068 seconds
>   build: 4.842 seconds
>   compile: 4.841 seconds
>   driver: 70.776 seconds
> Test results: passed: 1
> 
> 
> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
> 
> 
> Passed: containers/docker/TestJcmdWithSideCar.java
>   build: 2.169 seconds
>   compile: 2.157 seconds
>   build: 4.964 seconds
>   compile: 4.963 seconds
>   driver: 22.928 seconds
> Test results: passed: 1
> 
> 
> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue?...

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove the attachee container if it exists

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21289/files
  - new: https://git.openjdk.org/jdk/pull/21289/files/5b2f646c..ef7abf24

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

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

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

From sgehwolf at openjdk.org  Wed Oct  2 16:50:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 16:50:05 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <yRAug416JZ_JpDJxZqvyWWBkOy2wrP4F0o7TqWMr0e8=.1401ee86-3dc4-472d-9e87-27082beac81d@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <ZND-cslaoxC_yP_egRfXRzr8IZJbs_SZFsRwsqFBj24=.4487cc09-fd16-436e-a408-8de000bf894c@github.com>
 <XvrBkMP_s5mLBS3Qy6EfjAJbN5uOsuv6ZdjgBXI3ut8=.1e2e86ee-d87b-4745-8fa4-20bb5aa9a11b@github.com>
 <yRAug416JZ_JpDJxZqvyWWBkOy2wrP4F0o7TqWMr0e8=.1401ee86-3dc4-472d-9e87-27082beac81d@github.com>
Message-ID: <ZpRZTzh5aJ0-bEOsTaiNQ7a3aB1ibZiyNI_6OK47VZI=.885cd4a2-5f50-4146-9e5f-20acbda9f894@github.com>

On Wed, 2 Oct 2024 12:05:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> We'll have to do `docker rm -i /test-container-main` before we start a new one. I'll fix that later today.

Updated in https://github.com/openjdk/jdk/pull/21289/commits/ef7abf249268c30f726bee19dde3337d92c6493d If that doesn't work, I'll remove the test run time optimization.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389138766

From coleenp at openjdk.org  Wed Oct  2 17:37:54 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 2 Oct 2024 17:37:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v29]
In-Reply-To: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
Message-ID: <b0uXxDtd9PwrZvPhuZyn24UTaA8G4icxiQ5pX7qL4Bo=.c6c662fa-cae9-4f4c-885d-62ae9d3fe697@github.com>

On Wed, 2 Oct 2024 15:37:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>    
>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>  - Simplify object init code in interpreter
>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3

Thanks for making this change.  I've reviewed runtime, oops and metaspace code.  It looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2343632318

From duke at openjdk.org  Wed Oct  2 17:53:35 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 2 Oct 2024 17:53:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
Message-ID: <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>

On Wed, 2 Oct 2024 16:50:05 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> While at it, I've discovered that the `EventGeneratorLoop` running container always runs for a fixed time: `30` seconds. That's irrespective of the attacher containers being done. Therefore, two iterations of the loop spawning this container running the fixed set of time will at least run `60` seconds. In my test runs using `-summary:time` it was `70` seconds:
>> 
>> 
>> Passed: containers/docker/TestJcmdWithSideCar.java
>>   build: 2.08 seconds
>>   compile: 2.068 seconds
>>   build: 4.842 seconds
>>   compile: 4.841 seconds
>>   driver: 70.776 seconds
>> Test results: passed: 1
>> 
>> 
>> I don't think this is needed. We can destroy the process running `EventGeneratorLoop` and then wait for it to exit rather than sitting there and waiting until it is finished (even though we no longer do anything with it). This improvement has been implemented in https://github.com/openjdk/jdk/commit/5b2f646c73b747f6fff364347031074d24e49822 (separate commit). After this, the total runtime of the test reduces to about `22` seconds:
>> 
>> 
>> Passed: containers/docker/TestJcmdWithSideCar.java
>>   build: 2.169 seconds
>>   compile: 2.157 seconds
>>   build: 4.964 seconds
>>   compile: 4.963 seconds
>>   driver: 22.928 seconds
>> Test results: passed: 1
>> 
>> 
>> The actual test skip of the 4th test case is: https://github.com/openjdk/jdk/commit/95a7cc05f00e94190af583b9f9dbc659c7be879f
>> 
>> Thoughts? Could somebody please run th...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the attachee container if it exists

Right, this turned into a rabbit hole of its own.. ? 

`make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"` is still failing:


Full child process STDOUT was saved to docker-stdout-139602.log
[2024-10-02T17:02:06.397293068Z] Waiting for completion for process 139602
[2024-10-02T17:02:06.397362093Z] Waiting for completion finished for process 139602
[COMMAND]
docker ps 
[2024-10-02T17:02:07.771881444Z] Gathering output for process 139723
[ELAPSED: 19 ms]
[STDERR]

[STDOUT]
CONTAINER ID   IMAGE                                                              COMMAND                  CREATED         STATUS         PORTS     NAMES
1db392c08e7c   jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd   "/jdk/bin/java -XX:+?"   5 seconds ago   Up 5 seconds             test-container-main

Full child process STDOUT was saved to docker-stdout-139723.log
[2024-10-02T17:02:07.790740367Z] Waiting for completion for process 139723
[2024-10-02T17:02:07.790915466Z] Waiting for completion finished for process 139723
[COMMAND]
docker rm test-container-main 
[2024-10-02T17:02:07.792750591Z] Gathering output for process 139734
[ELAPSED: 15 ms]
[STDERR]
Error response from daemon: You cannot remove a running container 1db392c08e7cbac3a256597c2ee693fdbbeab3a814cb229c83ac38c0c805f42d. Stop the container before attempting removal or force remove


I _think_ the underlying problem is that killing the process from the Java test is not properly propagated to the `EventGeneratorLoop` process running as a Docker container. Among others, I found https://www.kaggle.com/code/residentmario/best-practices-for-propagating-signals-on-docker talking about it. So, in the Docker case the container continues running for the whole 30 seconds even though we called `p.destroy()`. `docker rm` for the next test case will fail because the container is still running. So, I started out by trying this:


diff --git test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
index 5132f14d788..4726284cff1 100644
--- test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
+++ test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
@@ -251,8 +251,9 @@ public Process start(final boolean elevated) throws Exception {
             OutputAnalyzer out = DockerTestUtils.execute(Container.ENGINE_COMMAND, "ps")
                 .shouldHaveExitValue(0);
             if (out.contains(MAIN_CONTAINER_NAME)) {
-                DockerTestUtils.execute(Container.ENGINE_COMMAND, "rm", MAIN_CONTAINER_NAME)
+                DockerTestUtils.execute(Container.ENGINE_COMMAND, "stop", "--time=1", "--signal=SIGKILL", MAIN_CONTAINER_NAME)
                    .shouldHaveExitValue(0);
             }
             // start "main" container (the observee)
             DockerRunOptions opts = commonDockerOpts("EventGeneratorLoop");


..only to be met by:


[main-container-process] docker: Error response from daemon: Conflict. The container name "/test-container-main" is already in use by container "f2754e97e6eecd6b0538e8a8c3d7c12214d16f9f32a9e2fe313c1d9f3258732c". You have to remove (or rename) that container to be able to reuse that name.
[main-container-process] See 'docker run --help'.
java.lang.RuntimeException: Timed out while waiting for main() to start
	at TestJcmdWithSideCar$MainContainer.waitForMainMethodStart(TestJcmdWithSideCar.java:293)
	at TestJcmdWithSideCar.main(TestJcmdWithSideCar.java:110)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)


Because we start containers with `--rm`, they seem to be asynchronously removed _after_ `stop` has finished. Finally, if we wait a little bit after the `stop` command, `make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"` works again.


diff --git test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
index 5132f14d788..4726284cff1 100644
--- test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
+++ test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
@@ -251,8 +251,9 @@ public Process start(final boolean elevated) throws Exception {
             OutputAnalyzer out = DockerTestUtils.execute(Container.ENGINE_COMMAND, "ps")
                 .shouldHaveExitValue(0);
             if (out.contains(MAIN_CONTAINER_NAME)) {
-                DockerTestUtils.execute(Container.ENGINE_COMMAND, "rm", MAIN_CONTAINER_NAME)
+                DockerTestUtils.execute(Container.ENGINE_COMMAND, "stop", "--time=1", "--signal=SIGKILL", MAIN_CONTAINER_NAME)
                    .shouldHaveExitValue(0);
+                Thread.sleep(1_000L);
             }
             // start "main" container (the observee)
             DockerRunOptions opts = commonDockerOpts("EventGeneratorLoop");

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389263714

From amenkov at openjdk.org  Wed Oct  2 17:54:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 2 Oct 2024 17:54:39 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
 [v2]
In-Reply-To: <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
 <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
Message-ID: <f3SqLBGKy-W_kvzNqmFZz9qFKMncBZVWFbVFocywiho=.1d45b64a-c732-4b6a-86a7-39f921ffa35b@github.com>

On Wed, 2 Oct 2024 02:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
>> 
>> char* translateThreadState(jint flags);
>> char* getThreadName(jthread thread);
>> char* getMethodName(jmethodID method);
>> void printStackTrace(jthread thread);
>> void printThreadInfo(jthread thread);
>> 
>> I made use of them while working on a couple of recent bugs and found them very useful. 
>> 
>> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21299#pullrequestreview-2343661989

From sgehwolf at openjdk.org  Wed Oct  2 18:30:37 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 18:30:37 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
 <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
Message-ID: <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>

On Wed, 2 Oct 2024 17:50:44 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> Right, this turned into a rabbit hole of its own.. ?

Thanks. I'll remove this part from the patch as it's orthogonal to the actual issue and would just like to get the test passing again.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389419514

From larry.cable at oracle.com  Wed Oct  2 18:31:47 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 2 Oct 2024 11:31:47 -0700
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
 <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
Message-ID: <c3eb0b4e-acb1-426c-95ae-e6edd503745d@oracle.com>

Daniel I plan to push a PR that will fix the attach code later today!

- Larry


On 10/2/24 8:44 AM, Daniel D. Daugherty wrote:
> On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:
>
>>> Hi all,
>>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>>> So this PR add `readlink` permission to make this test work normally.
>>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    merge two comments enclosed with /* ... */ on two lines
> @sendaoYan - This failure is quite noisy in the Oracle CI. We see
> many failures in Tier[567]. When will you be integrating your fix?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2388992950


From sgehwolf at openjdk.org  Wed Oct  2 18:46:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 18:46:07 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v3]
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!

Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "Improve runtime of test"
   
   This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
 - Revert "Remove the attachee container if it exists"
   
   This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21289/files
  - new: https://git.openjdk.org/jdk/pull/21289/files/ef7abf24..24a4303f

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

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

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

From sgehwolf at openjdk.org  Wed Oct  2 18:46:07 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 2 Oct 2024 18:46:07 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
 <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
 <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>
Message-ID: <MvAfkFUdDCjUHalnxmBbtVk89jB1ol-iJmODU_dxZEI=.981a2b5c-98f5-48a5-806e-ede3006b6fc4@github.com>

On Wed, 2 Oct 2024 18:28:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > Right, this turned into a rabbit hole of its own.. ?
> 
> Thanks. I'll remove this part from the patch as it's orthogonal to the actual issue and would just like to get the test passing again.

Filed https://bugs.openjdk.org/browse/JDK-8341436 to track this separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389444807

From duke at openjdk.org  Wed Oct  2 18:54:35 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 2 Oct 2024 18:54:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <XLuJlbHfWHXuSi4eTR0xuTagDBnpjCPezsAtKUVYL8Q=.7b911f35-e75b-483e-8a31-8ff5dad2ec4c@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

LGTM

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

Marked as reviewed by slovdahl at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/21289#pullrequestreview-2343841970

From alanb at openjdk.org  Wed Oct  2 18:59:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Oct 2024 18:59:09 GMT
Subject: RFR: 8339979: VirtualThreadSchedulerMXBeanTest.testReduceParallelism
 fails intermittently
Message-ID: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>

This is a test only change. VirtualThreadSchedulerMXBeanTest.testReduceParallelism can fail if getMountedVirtualThreadCount over estimates the number of mounted virtual threads.

The change is changed from using getMountedVirtualThreadCount to use an awaitXXX method that will sample the mounted virtual thread count until it reads an expected value.

As part of the change, the awaitXXX supporting methods are changed to take a predicate and the trace message.

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

Commit messages:
 - Initial commit

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

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

From duke at openjdk.org  Wed Oct  2 19:03:36 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 2 Oct 2024 19:03:36 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <MvAfkFUdDCjUHalnxmBbtVk89jB1ol-iJmODU_dxZEI=.981a2b5c-98f5-48a5-806e-ede3006b6fc4@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
 <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
 <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>
 <MvAfkFUdDCjUHalnxmBbtVk89jB1ol-iJmODU_dxZEI=.981a2b5c-98f5-48a5-806e-ede3006b6fc4@github.com>
Message-ID: <NtGKxoloTbjppno4UWouYsWrsNUQxhf2_bqbTnXAASY=.efa50199-f085-473f-a61a-ff20a501a558@github.com>

On Wed, 2 Oct 2024 18:42:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Filed https://bugs.openjdk.org/browse/JDK-8341436 to track this separate issue.

Do you intend to look into this yourself? If not, I would be happy to pick it up.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389475940

From duke at openjdk.org  Wed Oct  2 19:40:35 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 2 Oct 2024 19:40:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <XOjek5wc9BGFhU2WAd4CSnFqFNbG29yLHC77KHkRVGE=.cef74c34-a779-4fbe-9f2f-ad317c7d86f1@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

> It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).

I spent some time thinking about this, and I'm not sure if it can be solved?

The test case that fails with Podman is `ACCESS_TMP_VIA_PROC_ROOT`. That is, we try to attach to another JVM by accessing the target JVM's root filesystem through `/proc/[pid]/root`. But for processes with elevated privileges `/proc/[pid]/root` can only be read by `root`. That is why it works with the default setup of Docker but not Podman. Or am I missing something?

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2389535881

From larry.cable at oracle.com  Wed Oct  2 20:00:37 2024
From: larry.cable at oracle.com (Laurence Cable)
Date: Wed, 2 Oct 2024 13:00:37 -0700
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v2]
In-Reply-To: <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <gsCmqVbzFJ-CgakCsCM5RM0MKQsktoZhTYJbiuPkltU=.796508fc-9cf5-4f86-9225-bb8495888bd4@github.com>
 <oeUieiVohjL2lyeZuO3eR8o4dIiAWvXlryRwDkZNZFg=.7bb9e5d2-b17d-4101-844c-242e0d7509b7@github.com>
Message-ID: <ac6fc888-235f-44d5-8d52-1e655b42297f@oracle.com>

fix to 8327114 pushed. https://github.com/openjdk/jdk/pull/21312


On 10/2/24 8:44 AM, Daniel D. Daugherty wrote:
> On Tue, 1 Oct 2024 15:38:56 GMT, SendaoYan <syan at openjdk.org> wrote:
>
>>> Hi all,
>>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>>> So this PR add `readlink` permission to make this test work normally.
>>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    merge two comments enclosed with /* ... */ on two lines
> @sendaoYan - This failure is quite noisy in the Oracle CI. We see
> many failures in Tier[567]. When will you be integrating your fix?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2388992950


From duke at openjdk.org  Wed Oct  2 20:02:05 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 2 Oct 2024 20:02:05 GMT
Subject: RFR: JDK-8327114: fix to resolve permissions issue as per: 8341246
Message-ID: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>

this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 

to resolve an issue detected in: 

https://bugs.openjdk.org/browse/JDK-8341246

sym link file accesses should be performed as "privileged" actions.

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

Commit messages:
 - JDK-8327114: fix to resolve permissions issue as per: 8341246

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

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

From duke at openjdk.org  Wed Oct  2 20:02:05 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 2 Oct 2024 20:02:05 GMT
Subject: RFR: JDK-8327114: fix to resolve permissions issue as per: 8341246
In-Reply-To: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
Message-ID: <tMjFaWZr3qmR5uVeaMISp1uAqkMpSGE2OnGrHvlAAcg=.f68f5728-d817-43db-93f5-51c7c47ccc71@github.com>

On Wed, 2 Oct 2024 19:55:29 GMT, Larry Cable <duke at openjdk.org> wrote:

> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
> 
> to resolve an issue detected in: 
> 
> https://bugs.openjdk.org/browse/JDK-8341246
> 
> sym link file accesses should be performed as "privileged" actions.

@kevinjwalls @slovdahl @jerboaa @sendaoYan @dcubed-ojdk

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

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2389569445

From duke at openjdk.org  Wed Oct  2 21:15:11 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 2 Oct 2024 21:15:11 GMT
Subject: RFR: JDK-8327114: fix to resolve permissions issue as per: 8341246
 [v2]
In-Reply-To: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
Message-ID: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>

> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
> 
> to resolve an issue detected in: 
> 
> https://bugs.openjdk.org/browse/JDK-8341246
> 
> sym link file accesses should be performed as "privileged" actions.

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21312/files
  - new: https://git.openjdk.org/jdk/pull/21312/files/99a9b1b4..881bc574

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

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

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

From sviswanathan at openjdk.org  Wed Oct  2 21:31:52 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 2 Oct 2024 21:31:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
Message-ID: <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>

On Mon, 30 Sep 2024 17:48:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Wait a second, I've probably not been clear. `UseCompactObjectHeaders` is slated to become *on by default* and then slated to go away. That means that array base offets <= 16 bytes will become the default. The generated code will be something like:
>> 
>> 
>> if (haystack_len <= 8) {
>>   // Copy 8 bytes onto stack
>> } else if (haystack_len <= 16) {
>>   // Copy 16 bytes onto stack
>> } else {
>>   // Copy 32 bytes onto stack
>> }
>> 
>> 
>> So that is 2 branches in this prologue code instead of originally 1.
>> 
>> However, I just noticed that what I proposed is not enough. Consider what happens when haystack_len is 17. This would take the last case and copy 32 bytes. But we only have 17+8=25 bytes that we can guarantee to be available for copying. If this happens to be the array at the very beginning of the heap (very rare/unlikely), this would segfault.
>> 
>> I think I need to mull over it some more to come up with a correct fix.
>
> I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5
> 
> The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash).
> 
> I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.?
> 
> Also, this new implementation could simply replace the old one, instead of being an alternative. I am not sure if if would make any difference performance-wise.

@rkennke The small loop looks to me that it will run over the end of the array.
Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the  movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
       // num_words (zero-based) = (haystack_len - 1) / 8;
      __ movq(index, haystack_len);
      __ subq(index, 1);
      __ shrq(index, LogBytesPerWord);

      __ bind(L_loop);
      __ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
      __ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
      __ subq(index, 1);
      __ jcc(Assembler::positive, L_loop);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1785269849

From dhanalla at openjdk.org  Thu Oct  3 02:23:35 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 3 Oct 2024 02:23:35 GMT
Subject: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]
In-Reply-To: <EIgPRPPps4JFWQNlv_Gxp4Zo94bNVp3I3YSOenYP7Dg=.7518f304-0842-4102-9aad-0f039a2b8128@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
 <DJ8IvmHEzfE47eXog12PulhapiujIPgHUoDGAoUBsXw=.f71efc9d-20d3-4a8d-a296-5f1ec883faaf@github.com>
 <EIgPRPPps4JFWQNlv_Gxp4Zo94bNVp3I3YSOenYP7Dg=.7518f304-0842-4102-9aad-0f039a2b8128@github.com>
Message-ID: <LAmVop7jTMkdyWsk9mIYw1lFRu1mnZ0w01vkqxb_UQ8=.d6448823-062a-45b2-a0ac-eff3b3c14762@github.com>

On Thu, 26 Sep 2024 16:17:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Dhamoder Nalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix missing code
>
> I don't have a suggestion for maintaining compatibility other than not making the change.

Thank you @plummercj, @kevinjwalls,
We appreciate your concerns regarding compatibility. However, we implemented this change to enhance security. 
According to the documentation at https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha#remarks, it is recommended to use GetTempPath2. If you believe that compatibility is more critical than the security improvements we've made, we are willing to close the pull request.

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

PR Comment: https://git.openjdk.org/jdk/pull/20600#issuecomment-2390368801

From dholmes at openjdk.org  Thu Oct  3 02:20:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 3 Oct 2024 02:20:39 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
Message-ID: <Yq3pPb_rHl-Ll8852mh8YM2eUsdwSYYMl7p78PTbVy4=.5f801cc0-4c31-478c-bfa4-a16e3a50b434@github.com>

On Wed, 2 Oct 2024 13:28:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - 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>

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20852#pullrequestreview-2344511961

From duke at openjdk.org  Thu Oct  3 05:30:40 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 3 Oct 2024 05:30:40 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <NtGKxoloTbjppno4UWouYsWrsNUQxhf2_bqbTnXAASY=.efa50199-f085-473f-a61a-ff20a501a558@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
 <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
 <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>
 <MvAfkFUdDCjUHalnxmBbtVk89jB1ol-iJmODU_dxZEI=.981a2b5c-98f5-48a5-806e-ede3006b6fc4@github.com>
 <NtGKxoloTbjppno4UWouYsWrsNUQxhf2_bqbTnXAASY=.efa50199-f085-473f-a61a-ff20a501a558@github.com>
Message-ID: <hp0VYHSejUsy-gJxpp2NfoJx4mF4mlHvoCW12bFEUWQ=.25413ed2-0981-4f06-8a35-bc5918d0af69@github.com>

On Wed, 2 Oct 2024 19:01:19 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> > Filed https://bugs.openjdk.org/browse/JDK-8341436 to track this separate issue.
> 
> Do you intend to look into this yourself? If not, I would be happy to pick it up.

It finally occurred to my why `p.destroy()` doesn't seem to have any effect: the process the Java test sees is just a short-lived one that calls the Docker daemon. That is, it is _not_ a reference to the container process itself and it cannot stop the container. That needs to go through a `docker stop` call.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2390554034

From sgehwolf at openjdk.org  Thu Oct  3 08:03:34 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 08:03:34 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container)
In-Reply-To: <tMjFaWZr3qmR5uVeaMISp1uAqkMpSGE2OnGrHvlAAcg=.f68f5728-d817-43db-93f5-51c7c47ccc71@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <tMjFaWZr3qmR5uVeaMISp1uAqkMpSGE2OnGrHvlAAcg=.f68f5728-d817-43db-93f5-51c7c47ccc71@github.com>
Message-ID: <xVXpmkSP79fbP--Cra4zlL0kaKqbkT-TAA_ssMniqi0=.e0d47031-8bcb-4383-be69-38d3d7c81960@github.com>

On Wed, 2 Oct 2024 19:59:31 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> @kevinjwalls @slovdahl @jerboaa @sendaoYan @dcubed-ojdk

@larry-cable [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) is fixed. This PR should get integrated with a new bug. It cannot use the same bug unless it's a backport, which this clearly isn't. Also the permission issue is fixed with https://github.com/openjdk/jdk/pull/21269 (integrated).

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

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2390770485

From sgehwolf at openjdk.org  Thu Oct  3 08:06:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 08:06:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v2]
In-Reply-To: <hp0VYHSejUsy-gJxpp2NfoJx4mF4mlHvoCW12bFEUWQ=.25413ed2-0981-4f06-8a35-bc5918d0af69@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <RrrJLpyZHTTSZK5tWK7KyYoOOjPzsq-ZOKRL1DZ2qg0=.c36665e4-ac85-4fa7-a804-d9c33b77ea50@github.com>
 <e42BKWhxL_lCTnbCPRuIjfK6wlZkg8LC-CdUC57qhF8=.64a04380-ec40-4b2e-81fb-44924141e5a1@github.com>
 <e77NNCO05U0pPuUwufr1q3u2Mu0OXEOncmVnuVlwT2E=.1ecc5cd5-3f89-453c-9b63-1e153e1ddcd4@github.com>
 <MvAfkFUdDCjUHalnxmBbtVk89jB1ol-iJmODU_dxZEI=.981a2b5c-98f5-48a5-806e-ede3006b6fc4@github.com>
 <NtGKxoloTbjppno4UWouYsWrsNUQxhf2_bqbTnXAASY=.efa50199-f085-473f-a61a-ff20a501a558@github.com>
 <hp0VYHSejUsy-gJxpp2NfoJx4mF4mlHvoCW12bFEUWQ=.25413ed2-0981-4f06-8a35-bc5918d0af69@github.com>
Message-ID: <FrHOA6IZwS5R6Kzyc1mmEpBU0yGnNrxA8n5xoWzLmLE=.0ea5a995-e704-46dd-9252-16c6658101a7@github.com>

On Thu, 3 Oct 2024 05:27:33 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> > Filed https://bugs.openjdk.org/browse/JDK-8341436 to track this separate issue.
> 
> Do you intend to look into this yourself? If not, I would be happy to pick it up.

Please go ahead and have a go at this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2390775602

From kevinw at openjdk.org  Thu Oct  3 08:42:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 3 Oct 2024 08:42:35 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
Message-ID: <APYXOpql7EQusOY3yTT8dpT2yoV7s-JC9ArOG91dKnA=.433e6b21-1ae2-48b6-b49d-9002d02030b6@github.com>

On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

I tested and saw the permission problem in the test was fixed by the policy update.  But it's correct that it should really have a doPrivileged call, in case this happens with a Security Manager, and there's untrusted code which then calls into attach (with whatever policy permits that to happen...).

While SM is planned for removal very soon, it would be good have the doPrivileged in the implementation so any backports can benefit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2390845932

From alanb at openjdk.org  Thu Oct  3 09:03:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Oct 2024 09:03:06 GMT
Subject: RFR: 8339979:
 VirtualThreadSchedulerMXBeanTest.testReduceParallelism fails intermittently
 [v2]
In-Reply-To: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>
References: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>
Message-ID: <M7-ZzPNY-d-uYwfGaIhChGJcPWS3bs6rZSd0VN72foQ=.82a72d93-a199-4624-b6ec-9846954a013a@github.com>

> This is a test only change. VirtualThreadSchedulerMXBeanTest.testReduceParallelism can fail when getMountedVirtualThreadCount over estimates the number of mounted virtual threads.
> 
> The test is changed from using getMountedVirtualThreadCount to sample the result until it reads the expected value.
> 
> As part of the change, the awaitXXX supporting methods are refactored to take a predicate and the trace message.

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

  Bring back Gte/Lte methods, reduces changes to one test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21310/files
  - new: https://git.openjdk.org/jdk/pull/21310/files/d65a371c..be9e8b92

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

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

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

From sgehwolf at openjdk.org  Thu Oct  3 09:35:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 09:35:35 GMT
Subject: RFR: 8327114: Attach in Linux may have wrong behaviour when pid ==
 ns_pid (Kubernetes debug container) [v2]
In-Reply-To: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
Message-ID: <3SM1_PdGMqnY6gcjdXMN-Ww7aelcKVxKS4Nw_MBxFjQ=.4f53c2a2-02a0-4427-beea-9a9eb5600cfd@github.com>

On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

Yes, agreed. But we need a new bug for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2390953016

From kevinw at openjdk.org  Thu Oct  3 09:39:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 3 Oct 2024 09:39:36 GMT
Subject: RFR: 8339979:
 VirtualThreadSchedulerMXBeanTest.testReduceParallelism fails intermittently
 [v2]
In-Reply-To: <M7-ZzPNY-d-uYwfGaIhChGJcPWS3bs6rZSd0VN72foQ=.82a72d93-a199-4624-b6ec-9846954a013a@github.com>
References: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>
 <M7-ZzPNY-d-uYwfGaIhChGJcPWS3bs6rZSd0VN72foQ=.82a72d93-a199-4624-b6ec-9846954a013a@github.com>
Message-ID: <2rNASxxRjzZ8FHyAN5cIbhAVUP9QW5SsONv5g_kzEjI=.23451e9c-a648-4d0b-9308-89ef03116806@github.com>

On Thu, 3 Oct 2024 09:03:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a test only change. VirtualThreadSchedulerMXBeanTest.testReduceParallelism can fail when getMountedVirtualThreadCount over estimates the number of mounted virtual threads.
>> 
>> The test is changed from using getMountedVirtualThreadCount to sample the result until it reads the expected value.
>> 
>> As part of the change, the awaitXXX supporting methods are refactored to take a predicate and the trace message.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back Gte/Lte methods, reduces changes to one test

Hi, looks really good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21310#pullrequestreview-2345117198

From sgehwolf at openjdk.org  Thu Oct  3 10:21:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 10:21:35 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114
In-Reply-To: <zpVOtBu9QdTgXj6eWjDcJuUPrfJvouvN_P4m7UDJd7E=.1affce5a-634f-4039-b93a-b540839b7c91@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <zpVOtBu9QdTgXj6eWjDcJuUPrfJvouvN_P4m7UDJd7E=.1affce5a-634f-4039-b93a-b540839b7c91@github.com>
Message-ID: <P9l9EbKYgONFavXfaq_Iv4VmlXBmhV9R9Nc8Pi1w5uo=.1f81d799-35f5-4ac7-969c-7fb59633be85@github.com>

On Tue, 1 Oct 2024 16:56:11 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I can check our testing with this change...

@kevinjwalls Any update on this? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2391044188

From kevinw at openjdk.org  Thu Oct  3 10:46:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 3 Oct 2024 10:46:37 GMT
Subject: RFR: 8341310: Test containers/docker/TestJcmdWithSideCar.java
 fails after JDK-8327114 [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <SBLBMmOaZNz56lrJzYyewJOQwjbMVfjaCdDqJkedI80=.2197ac24-810a-4d71-bef3-7c7c86673a60@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

Good timing, I was just writing:

Thanks, looks good.  Good to delay the additional changes.
Would be great if you can change the bug and PR title to something like:
8341310: Test TestJcmdWithSideCar.java should skip ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114)
(Multiple "test fails after..." bugs are confusing to me at least!)

With the test as it stands in the repo currently, I am seeing another failure.  I don't get this myself with the change in this PR, but that may just be luck.  

It's on Linux x64, with TMP_MOUNTED_INTO_SIDECAR, where the command:

docker run --tty=true --rm --cap-add=SYS_PTRACE --sig-proxy=true --pid=container:test-container-main --cap-add=NET_BIND_SERVICE --user=10668:10668 --volumes-from test-container-main jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd /jdk/bin/jcmd -l 

...gets no output, where a good run would show:

[STDOUT]
1 EventGeneratorLoop 120
24 jdk.jcmd/sun.tools.jcmd.JCmd -l

e.g.


[main-container-process] MAIN_METHOD_STARTED, argument is 120
Attach strategy TMP_MOUNTED_INTO_SIDECAR
[COMMAND]
docker run --tty=true --rm --cap-add=SYS_PTRACE --sig-proxy=true --pid=container:test-container-main --cap-add=NET_BIND_SERVICE --user=10668:10668 --volumes-from test-container-main jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd /jdk/bin/jcmd -l 
[2024-10-03T04:30:35.273416534Z] Gathering output for process 12125
[ELAPSED: 1068 ms]
[STDERR]

[STDOUT]

Full child process STDOUT was saved to docker-stdout-12125.log
[2024-10-03T04:30:36.341378706Z] Waiting for completion for process 12125
[2024-10-03T04:30:36.341534140Z] Waiting for completion finished for process 12125
[COMMAND]
docker rmi --force jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd 
[2024-10-03T04:30:36.349399928Z] Gathering output for process 12260
[ELAPSED: 27 ms]
[STDERR]

[STDOUT]
Untagged: jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd

Full child process STDOUT was saved to docker-stdout-12260.log
----------System.err:(16/748)----------
 stdout: [];
 stderr: []
 exitValue = 0

java.lang.RuntimeException: 'sun.tools.jcmd.JCmd' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
	at TestJcmdWithSideCar.testCase01(TestJcmdWithSideCar.java:135)
	at TestJcmdWithSideCar.main(TestJcmdWithSideCar.java:111)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1576)

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2391093691

From sgehwolf at openjdk.org  Thu Oct  3 12:20:36 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 12:20:36 GMT
Subject: RFR: 8341310: Test TestJcmdWithSideCar.java should skip
 ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114) [v3]
In-Reply-To: <SBLBMmOaZNz56lrJzYyewJOQwjbMVfjaCdDqJkedI80=.2197ac24-810a-4d71-bef3-7c7c86673a60@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
 <SBLBMmOaZNz56lrJzYyewJOQwjbMVfjaCdDqJkedI80=.2197ac24-810a-4d71-bef3-7c7c86673a60@github.com>
Message-ID: <kdOWYfd2T4zzDt4MCU58AhYdW6JyKKUiJ07lfHlbk1U=.6180072c-1bf4-4730-bcf0-8337200f1d16@github.com>

On Thu, 3 Oct 2024 10:43:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "Improve runtime of test"
>>    
>>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>>  - Revert "Remove the attachee container if it exists"
>>    
>>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.
>
> Good timing, I was just writing:
> 
> Thanks, looks good.  Good to delay the additional changes.
> Would be great if you can change the bug and PR title to something like:
> 8341310: Test TestJcmdWithSideCar.java should skip ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114)
> (Multiple "test fails after..." bugs are confusing to me at least!)
> 
> With the test as it stands in the repo currently, I am seeing another failure.  I don't get this myself with the change in this PR, but that may just be luck.  
> 
> It's on Linux x64, with TMP_MOUNTED_INTO_SIDECAR, where the command:
> 
> docker run --tty=true --rm --cap-add=SYS_PTRACE --sig-proxy=true --pid=container:test-container-main --cap-add=NET_BIND_SERVICE --user=10668:10668 --volumes-from test-container-main jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd /jdk/bin/jcmd -l 
> 
> ...gets no output, where a good run would show:
> 
> [STDOUT]
> 1 EventGeneratorLoop 120
> 24 jdk.jcmd/sun.tools.jcmd.JCmd -l
> 
> e.g.
> 
> 
> [main-container-process] MAIN_METHOD_STARTED, argument is 120
> Attach strategy TMP_MOUNTED_INTO_SIDECAR
> [COMMAND]
> docker run --tty=true --rm --cap-add=SYS_PTRACE --sig-proxy=true --pid=container:test-container-main --cap-add=NET_BIND_SERVICE --user=10668:10668 --volumes-from test-container-main jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd /jdk/bin/jcmd -l 
> [2024-10-03T04:30:35.273416534Z] Gathering output for process 12125
> [ELAPSED: 1068 ms]
> [STDERR]
> 
> [STDOUT]
> 
> Full child process STDOUT was saved to docker-stdout-12125.log
> [2024-10-03T04:30:36.341378706Z] Waiting for completion for process 12125
> [2024-10-03T04:30:36.341534140Z] Waiting for completion finished for process 12125
> [COMMAND]
> docker rmi --force jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd 
> [2024-10-03T04:30:36.349399928Z] Gathering output for process 12260
> [ELAPSED: 27 ms]
> [STDERR]
> 
> [STDOUT]
> Untagged: jdk-internal:test-containers-docker-TestJcmdWithSideCar-jfr-jcmd
> 
> Full child process STDOUT was saved to docker-stdout-12260.log
> ----------System.err:(16/748)----------
>  stdout: [];
>  stderr: []
>  exitValue = 0
> 
> java.lang.RuntimeException: 'sun.tools.jcmd.JCmd' missing from stdout/stderr
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:253)
> 	at TestJcmdWithSideCar.testCase01(TestJcmdWithSideCar.java:135)
> 	at TestJcmdWithSideCar.main(TestJcmdWithSideCar.java:111)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Met...

@kevinjwalls

> Thanks, looks good. Good to delay the additional changes. Would be great if you can change the bug and PR title to something like: 8341310: Test TestJcmdWithSideCar.java should skip ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114) (Multiple "test fails after..." bugs are confusing to me at least!)

OK. Done.
 
> With the test as it stands in the repo currently, I am seeing another failure. I don't get this myself with the change in this PR, but that may just be luck.

I'm confused. Are you saying that after this patch in revision https://github.com/openjdk/jdk/pull/21289/commits/24a4303f75fb854098a74ddf6be98a7981a45cc8 there are still failures in Oracle's CI?

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2391275788

From kevinw at openjdk.org  Thu Oct  3 12:42:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 3 Oct 2024 12:42:36 GMT
Subject: RFR: 8341310: Test TestJcmdWithSideCar.java should skip
 ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114) [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <f3lhMN-Z0wMEneKw6sXv3Xgt1dtMk3rvqHiZmEVHljA=.c71dbd70-22b1-4548-b1c8-01c6c37751f4@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

Marked as reviewed by kevinw (Reviewer).

Sorry, was saying that the other failure type, ("'sun.tools.jcmd.JCmd' missing") is happening now in CI.  I have not reproduced it with the change in this PR.

But, as that "other" failure is happening with "sidecar", skipping ACCESS_TMP_VIA_PROC_ROOT should not fix it?  So maybe there is e.g. a chance/timing problem.

Either way, this change as it stands is still good, I think we should get it in to minimise the problems.  I can monitor and see if the "JCmd missing" problem happens again.

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

PR Review: https://git.openjdk.org/jdk/pull/21289#pullrequestreview-2345497444
PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2391318529

From sgehwolf at openjdk.org  Thu Oct  3 12:58:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 12:58:41 GMT
Subject: RFR: 8341310: Test TestJcmdWithSideCar.java should skip
 ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114) [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <SoP_aTxOfegxL_VDlMBI5f6mOTGH2MobMRdWTj0y9N4=.7fe4bd71-c97c-4591-ab67-226c10060ea8@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2391348632

From sgehwolf at openjdk.org  Thu Oct  3 12:58:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 3 Oct 2024 12:58:42 GMT
Subject: Integrated: 8341310: Test TestJcmdWithSideCar.java should skip
 ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114)
In-Reply-To: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
Message-ID: <l5jjludb9OWEntg5FJQNUGD8q-axGw8UdTMHeHiE58Y=.ff2ea338-0de3-4186-90e1-cd6488ff5e74@github.com>

On Tue, 1 Oct 2024 16:16:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
> 
> 1. Shared volumes between attachee and attacher and shared pid namespace
> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
> 3. Shared pid namespace between attachee and attacher only
> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
> 
> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
> 
> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!

This pull request has now been integrated.

Changeset: 21f8ccf4
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21f8ccf4a97313593f210f9a07e56d5ff92b7aa5
Stats:     9 lines in 1 file changed: 8 ins; 1 del; 0 mod

8341310: Test TestJcmdWithSideCar.java should skip ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114)

Reviewed-by: kevinw

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

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

From alanb at openjdk.org  Thu Oct  3 14:05:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Oct 2024 14:05:40 GMT
Subject: Integrated: 8339979:
 VirtualThreadSchedulerMXBeanTest.testReduceParallelism fails intermittently
In-Reply-To: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>
References: <dV2rbJalvhH8vpiLAxAOHZK80XeOdqc74xXbHwf4N6I=.12d2690f-5044-43c4-98d4-cb581c1052af@github.com>
Message-ID: <qPFPU6wGKukXpamTJK5j9F4B8VgUE1Zw91NNDlpxB2A=.99d58b6f-f968-4593-a884-7ad380dcd1b0@github.com>

On Wed, 2 Oct 2024 18:34:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change. VirtualThreadSchedulerMXBeanTest.testReduceParallelism can fail when getMountedVirtualThreadCount over estimates the number of mounted virtual threads.
> 
> The test is changed from using getMountedVirtualThreadCount to sample the result until it reads the expected value.
> 
> As part of the change, the awaitXXX supporting methods are refactored to take a predicate and the trace message.

This pull request has now been integrated.

Changeset: eb93e695
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb93e6952b5d2dbe78cd9680855ac99c69b3dcb2
Stats:     80 lines in 1 file changed: 57 ins; 8 del; 15 mod

8339979: VirtualThreadSchedulerMXBeanTest.testReduceParallelism fails intermittently

Reviewed-by: kevinw

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

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

From duke at openjdk.org  Thu Oct  3 17:22:38 2024
From: duke at openjdk.org (Larry Cable)
Date: Thu, 3 Oct 2024 17:22:38 GMT
Subject: RFR: 8341482: Attach API access to /proc filesystem should use
 doPrivileged [v2]
In-Reply-To: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
Message-ID: <MQC5QKQ_JrzkkQb0-nSwIQX97SG_bmeUAWOv6f651ow=.c43d4989-d976-4b03-971b-b31de77cf274@github.com>

On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

done

wondering if the other filesystem operations in VirtualMachineImpl also need to be wrapped in doPrivileged blocks - since I'm not aware of any issues I'll assume not and patiently wait for the SecurityManager to be consigned to history.

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

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2391933529
PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2391936122

From cjplummer at openjdk.org  Thu Oct  3 18:48:42 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 3 Oct 2024 18:48:42 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
 [v2]
In-Reply-To: <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
 <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
Message-ID: <L8Xev9hQcQsEQUvW2ncYtaUW6u1MQCSYoiXOX8t-rKE=.47bf7806-1412-4164-b5be-4189cc34c9c6@github.com>

On Wed, 2 Oct 2024 02:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
>> 
>> char* translateThreadState(jint flags);
>> char* getThreadName(jthread thread);
>> char* getMethodName(jmethodID method);
>> void printStackTrace(jthread thread);
>> void printThreadInfo(jthread thread);
>> 
>> I made use of them while working on a couple of recent bugs and found them very useful. 
>> 
>> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Can I get a 2nd review please? thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/21299#issuecomment-2392092514

From coleenp at openjdk.org  Thu Oct  3 20:30:56 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 3 Oct 2024 20:30:56 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v29]
In-Reply-To: <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <migFoRhtd3kovSs2fRSGXzdh7vCpbyazoT5Gwzeu8ks=.4bd5afae-9598-4ab3-a7d8-737281236a4e@github.com>
Message-ID: <GqmziZEDXAdRD3_7_SwIQoRphkc_Vk3jR_16rNnV1_8=.57f3b695-549d-472a-9b04-2bb34e9d22d6@github.com>

On Wed, 2 Oct 2024 15:37:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>    
>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>  - Simplify object init code in interpreter
>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3

I posted a patch for JDK-8341044 for CDSPluginTest.java that was failing in our testing with the Lilliput patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2392273233

From duke at openjdk.org  Fri Oct  4 05:16:34 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Fri, 4 Oct 2024 05:16:34 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run
In-Reply-To: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
Message-ID: <jqJALNDqms2oV07RrtagAnYO2PCLWuqYbtANMC8BKFo=.c48f405b-a9ad-4521-a808-eb0fbd25f6f5@github.com>

On Thu, 3 Oct 2024 19:13:46 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> The fix is twofold.
> 
> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
> 
> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
> 
> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
> 
> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
> 
> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
> 
> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.

This was tested with


$ head -n 4 /etc/os-release 
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"

$ docker --version
Docker version 24.0.7, build 24.0.7-0ubuntu4.1

$ podman --version
podman version 4.9.3

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2392837773

From kevinw at openjdk.org  Fri Oct  4 08:17:41 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 4 Oct 2024 08:17:41 GMT
Subject: RFR: 8341310: Test TestJcmdWithSideCar.java should skip
 ACCESS_TMP_VIA_PROC_ROOT (after JDK-8327114) [v3]
In-Reply-To: <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
References: <sdSz7dGeDszDmAXB3kJZ5sqybyjDWPgJddJXzTsksoE=.521abe3d-32a7-415f-b0e0-a76cd020b159@github.com>
 <MOM4KszhaQtsiD2uKCHPhigxxTbfmuGnPrhRoIiTeXg=.0d3aaa9c-f7f0-4cb3-8019-077153852cef@github.com>
Message-ID: <HacLZKEZwnPmD1qoD-iAFUPh-ELlZ_HigiNCXcKsR2s=.09154d33-4c8b-4a67-8a72-f7ed25065b79@github.com>

On Wed, 2 Oct 2024 18:46:07 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change of [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) also increased test coverage. In particular, the `TestJcmdWithSideCar.java` test got enhanced to cover these cases (prior to [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114) only case 1 was tested):
>> 
>> 1. Shared volumes between attachee and attacher and shared pid namespace
>> 2. Shared volumes between attachee and attacher and shared pid namespace, both running with elevated privileges
>> 3. Shared pid namespace between attachee and attacher only
>> 4. Shared pid namespace between attachee and attacher, both running with elevated privileges
>> 
>> The OpenJDK attach code is able to handle cases 1 through 3 which pass, but the last case, `4`, hasn't been implemented yet when running as regular user and directing the container runtime to map the container user to that user as well. Thus, the test fails. For now I propose to disable the 4th test case. It can get re-enabled once the product code got updated to account for this case (tracked in https://bugs.openjdk.org/browse/JDK-8341349).
>> 
>> Thoughts? Could somebody please run this through Oracle's test system in order to see if this fixes the issue? Thank you!
>
> Severin Gehwolf has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "Improve runtime of test"
>    
>    This reverts commit 5b2f646c73b747f6fff364347031074d24e49822.
>  - Revert "Remove the attachee container if it exists"
>    
>    This reverts commit ef7abf249268c30f726bee19dde3337d92c6493d.

This change is working, having the intended effect. 8-)
I logged https://bugs.openjdk.org/browse/JDK-8341518 to follow up the separate intermittent failure we are seeing:
java.lang.RuntimeException: 'sun.tools.jcmd.JCmd' missing from stdout/stderr

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

PR Comment: https://git.openjdk.org/jdk/pull/21289#issuecomment-2393111779

From rkennke at openjdk.org  Fri Oct  4 10:44:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 4 Oct 2024 10:44:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
Message-ID: <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>

On Wed, 2 Oct 2024 21:29:28 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> I changed the header<16 version to be a small loop: https://github.com/rkennke/jdk/commit/bcba264ea5c15581647933db1163ca1dae39b6c5
>> 
>> The idea is the same as before, except it's made as a small loop with a maximum of 4 iterations (backward-branches), and it copies 8 bytes at a time, such that 1. it may copy up to 7 bytes that precede the array and 2. doesn't run over the end of the array (which would potentially crash).
>> 
>> I am not sure if using XMM_TMP1 and XMM_TMP2 there is ok, or if it would encode better to use one of the regular registers.?
>> 
>> Also, this new implementation could simply replace the old one, instead of being an alternative. I am not sure if if would make any difference performance-wise.
>
> @rkennke The small loop looks to me that it will run over the end of the array.
> Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the  movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
>        // num_words (zero-based) = (haystack_len - 1) / 8;
>       __ movq(index, haystack_len);
>       __ subq(index, 1);
>       __ shrq(index, LogBytesPerWord);
> 
>       __ bind(L_loop);
>       __ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
>       __ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
>       __ subq(index, 1);
>       __ jcc(Assembler::positive, L_loop);

Yes, and that is intentional.

Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.

Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.

Then comes the actual loop.

Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1787528501

From rkennke at openjdk.org  Fri Oct  4 11:15:37 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 4 Oct 2024 11:15:37 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:

 - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
 - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
   
   This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
 - Simplify object init code in interpreter
 - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
 - Fix for CDSPluginTest.java
 - Merge tag 'jdk-24+18' into JDK-8305895-v4
   
   Added tag jdk-24+18 for changeset 19642bd3
 - Disable TestSplitPacks::test4a, failing on aarch64
 - @robcasloz review comments
 - Improve CollectedHeap::is_oop()
 - Allow LM_MONITOR on 32-bit platforms
 - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=29
  Stats: 4560 lines in 196 files changed: 3207 ins; 724 del; 629 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From sspitsyn at openjdk.org  Fri Oct  4 11:58:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 4 Oct 2024 11:58:37 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
 [v2]
In-Reply-To: <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
 <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
Message-ID: <s6q51BEpH3YtDbnlR_eP-PWHYiqeWaxilYlPPDvylcY=.2d6b0b3b-17df-4648-be3d-0b5cb33065eb@github.com>

On Wed, 2 Oct 2024 02:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
>> 
>> char* translateThreadState(jint flags);
>> char* getThreadName(jthread thread);
>> char* getMethodName(jmethodID method);
>> void printStackTrace(jthread thread);
>> void printThreadInfo(jthread thread);
>> 
>> I made use of them while working on a couple of recent bugs and found them very useful. 
>> 
>> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21299#pullrequestreview-2347879062

From coleenp at openjdk.org  Fri Oct  4 12:53:53 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 4 Oct 2024 12:53:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
Message-ID: <lHkEF3XJ_h4c3dOro7V35aYk154SucAB8p7Px-2eLyI=.e4680e9a-1df7-47d1-adbc-203e85861035@github.com>

On Fri, 4 Oct 2024 11:15:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>    
>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>  - Simplify object init code in interpreter
>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>  - Fix for CDSPluginTest.java
>  - Merge tag 'jdk-24+18' into JDK-8305895-v4
>    
>    Added tag jdk-24+18 for changeset 19642bd3
>  - Disable TestSplitPacks::test4a, failing on aarch64
>  - @robcasloz review comments
>  - Improve CollectedHeap::is_oop()
>  - Allow LM_MONITOR on 32-bit platforms
>  - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1

There's another test failure that we're seeing that's similar to this bug in mainline when running with -XX:+UseCompactObjectHeaders on aarch64: https://bugs.openjdk.org/browse/JDK-8340212

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2393637283

From wkemper at openjdk.org  Fri Oct  4 18:21:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Oct 2024 18:21:34 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v2]
In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
Message-ID: <BneyQG9faYqRCvUeqGbfun-y4bno0I4KR15685D0gZ0=.94c5052d-cb02-40d2-b158-f3c9d85ceffc@github.com>

> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.

William Kemper 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 475 additional commits since the last revision:

 - Merge branch 'shenandoah/master' into great-genshen-pr-redux
 - Merge
 - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
   
   Reviewed-by: kdnilsen
 - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
   
   Reviewed-by: kdnilsen, ysr
 - Merge
 - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
   
   Reviewed-by: kdnilsen
 - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
   
   Reviewed-by: kdnilsen, shade, ysr
 - Merge
 - 8339643: Port JEP 404 to RISC-V
   
   Reviewed-by: wkemper, kdnilsen
 - 8340395: GenShen: Remove unnecessary check on card barrier flag
   
   Reviewed-by: ysr
 - ... and 465 more: https://git.openjdk.org/jdk/compare/143b2cd8...ed16e3ec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21273/files
  - new: https://git.openjdk.org/jdk/pull/21273/files/8b25abe0..ed16e3ec

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

  Stats: 25330 lines in 433 files changed: 21577 ins; 2314 del; 1439 mod
  Patch: https://git.openjdk.org/jdk/pull/21273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273

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

From cjplummer at openjdk.org  Fri Oct  4 20:08:39 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 4 Oct 2024 20:08:39 GMT
Subject: RFR: 8341295: Add some useful debugging APIs to the debug agent
 [v2]
In-Reply-To: <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
 <o1guTuVyaN-itFFwzuUsODhed8ffb5_B41y_Hle5cjg=.c82327fe-157d-4156-906a-27f717e67a99@github.com>
Message-ID: <tz5GMaNZ7v4gPrHi9wjYHLygamhw8gp019YCZzfyehM=.24b86670-dca0-40ad-94e7-6b212651384f@github.com>

On Wed, 2 Oct 2024 02:20:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
>> 
>> char* translateThreadState(jint flags);
>> char* getThreadName(jthread thread);
>> char* getMethodName(jmethodID method);
>> void printStackTrace(jthread thread);
>> void printThreadInfo(jthread thread);
>> 
>> I made use of them while working on a couple of recent bugs and found them very useful. 
>> 
>> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Thanks for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/21299#issuecomment-2394490693

From cjplummer at openjdk.org  Fri Oct  4 21:19:51 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 4 Oct 2024 21:19:51 GMT
Subject: Integrated: 8341295: Add some useful debugging APIs to the debug agent
In-Reply-To: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
References: <xgoobLvgIOM58mD24U1B5lZ826drclJcXoHuoWIH_9U=.ac36c47f-df6d-467d-ad78-f78d0861c0dd@github.com>
Message-ID: <Wk4lCDtHz5VXqp12mfZmz4gNpoDdTtphcGh478yJoX0=.eec0c388-a7d5-450a-b6cd-b678ca9d6ff2@github.com>

On Tue, 1 Oct 2024 21:58:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The following APIs are useful when debugging the debug agent. Calls to them can be added to the code as needed (temporarily) to aid in debugging issues. They were taken from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp` and modified to better fit the needs and coding style of the debug agent.
> 
> char* translateThreadState(jint flags);
> char* getThreadName(jthread thread);
> char* getMethodName(jmethodID method);
> void printStackTrace(jthread thread);
> void printThreadInfo(jthread thread);
> 
> I made use of them while working on a couple of recent bugs and found them very useful. 
> 
> Tested by running all debugging tests on all supported platforms, and also running tier2, tier3, and tier5 svc ci test tasks.

This pull request has now been integrated.

Changeset: 33e4bfdf
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/33e4bfdf919c44bebcf122818ab92deeb1f1cdce
Stats:     188 lines in 2 files changed: 188 ins; 0 del; 0 mod

8341295: Add some useful debugging APIs to the debug agent

Reviewed-by: amenkov, sspitsyn

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

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

From syan at openjdk.org  Sat Oct  5 03:29:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 5 Oct 2024 03:29:39 GMT
Subject: RFR: 8341246: Test com/sun/tools/attach/PermissionTest.java fails
 access denied after JDK-8327114 [v3]
In-Reply-To: <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
References: <_QJIWTQHDLJKjHfmY-PcVwgEYVodnSnN-FrvypFE0ys=.a61f9d5f-0a9e-4fc4-86cb-18c23d24d95f@github.com>
 <BTzpX0zPQTdXlVKOXsxg4rQqDqVxEp4qXSW-p8APbjk=.ac0cf3b8-e1bd-4fac-952d-bae887ab1e40@github.com>
Message-ID: <IcqKhjPE57GHOXAyJShtx2m-RPqqAMtolNeTdleIzkk=.d3f520af-0e98-4c19-bd96-cbe3516a5e1d@github.com>

On Wed, 2 Oct 2024 15:44:58 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Test `com/sun/tools/attach/PermissionTest.java` fails access denied after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114). This testcase need the `readlink` permission of file `/proc/self/ns/mnt` after [JDK-8327114](https://bugs.openjdk.org/browse/JDK-8327114).
>> So this PR add `readlink` permission to make this test work normally.
>> Before this PR, test run failed, after this PR, test run success. Test fix only, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make the comment of java.io.FilePermission look more elegant

Thanks all for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/21269#issuecomment-2394883598

From stefank at openjdk.org  Mon Oct  7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
Message-ID: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>

On Fri, 4 Oct 2024 11:15:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
> 
>  - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>    
>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>  - Simplify object init code in interpreter
>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>  - Fix for CDSPluginTest.java
>  - Merge tag 'jdk-24+18' into JDK-8305895-v4
>    
>    Added tag jdk-24+18 for changeset 19642bd3
>  - Disable TestSplitPacks::test4a, failing on aarch64
>  - @robcasloz review comments
>  - Improve CollectedHeap::is_oop()
>  - Allow LM_MONITOR on 32-bit platforms
>  - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1

I realize that some of my comments was stuck as drafts and had not been published. I took an extra pass over the gc/ and most of oops/ with the intention to approve those parts. However, I see that the comment about `fill_dense_prefix_end` and `MinObjectAlignment` has not been addressed. I don't know if that change is correct, so it would be good to get that scrutinized.

src/hotspot/share/gc/shared/collectedHeap.cpp line 223:

> 221: }
> 222: 
> 223: bool klass_is_sane(oop object) {

Should at least be static. We might also want to keep reporting errors if a klass pointer is null when we don't have a forwarded object:

static bool klass_is_sane(oop object) {
  if (UseCompactObjectHeaders) {
    // With compact headers, we can't safely access the Klass* when
    // the object has been forwarded, because non-full-GC-forwarding
    // distinction between Full-GC and regular GC forwarding.
    markWord mark = object->mark();
    if (mark.is_forwarded()) {
      // We can't access the Klass*. We optimistically assume that
      // it is ok. This happens very rarely.
      return true;
    }

    return Metaspace::contains(mark.klass_without_asserts());
  }

  return Metaspace::contains(object->klass_without_asserts());
}

src/hotspot/share/oops/compressedKlass.cpp line 28:

> 26: #include "logging/log.hpp"
> 27: #include "memory/metaspace.hpp"
> 28: #include "oops/klass.hpp"

Is this include really needed or could this be reverted klass.hpp? If it is needed is should be moved to after compressedKlass.inline.hpp.

src/hotspot/share/oops/compressedKlass.cpp line 31:

> 29: #include "oops/compressedKlass.inline.hpp"
> 30: #include "runtime/globals.hpp"
> 31: #include "runtime/java.hpp"

Do you remember why this was added?

src/hotspot/share/oops/markWord.cpp line 35:

> 33: STATIC_ASSERT(markWord::klass_shift + markWord::klass_bits == 64);
> 34: // The hash (preceding nKlass) shall be a direct neighbor but not interleave
> 35: STATIC_ASSERT(markWord::klass_shift == markWord::hash_bits + markWord::hash_shift);

The code is not consistent in it usage of the name for the klass bits. Here it says `nKlass` in the comment, but the fields are named `klass`. Maybe just change the comment to says `(preceding klass bits)`.

Note that the term `nklass` is not prevalent in the code base, but with this patch its starting to get a foot hold. It might be good to figure out what we do want to call these in field names and variables to at least a little bit more consistency in the code base. Currently we have `nklass`, `nKlass` `nk`, `narrow_klass`.

 In other places we have functions that are named `set_narrow_klass`, but the field is called `nklass` and other places call it `nk`. It would be good to stay consistent with the naming. FWIW, nklass has very little precedence in the code, so cleaning that away might be easiest.thing is to clean out all usages of nklass, because it isn't a

src/hotspot/share/oops/markWord.inline.hpp line 35:

> 33:   assert(UseCompactObjectHeaders, "only used with compact object headers");
> 34:   const narrowKlass nk = value() >> klass_shift;
> 35:   return narrowKlass(value() >> klass_shift);

This sets up an unused variable.
```suggestion 
  const narrowKlass nk = value() >> klass_shift;
  return narrowKlass(value() >> klass_shift);

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2331450326
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1777180846
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789757910
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789759027
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789787634
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789790323

From stefank at openjdk.org  Mon Oct  7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
Message-ID: <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>

On Thu, 19 Sep 2024 05:36:41 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 787:
>> 
>>> 785:     // The gap is always equal to min-fill-size, so nothing to do.
>>> 786:     return;
>>> 787:   }
>> 
>> Reading the comment, it is not obvious that this is correct if you set MinObjectAlignment to something larger than the default value:
>> 
>> void PSParallelCompact::fill_dense_prefix_end(SpaceId id) {
>>   // Comparing two sizes to decide if filling is required:
>>   //
>>   // The size of the filler (min-obj-size) is 2 heap words with the default
>>   // MinObjAlignment, since both markword and klass take 1 heap word.
>>   //
>>   // The size of the gap (if any) right before dense-prefix-end is
>>   // MinObjAlignment.
>>   //
>>   // Need to fill in the gap only if it's smaller than min-obj-size, and the
>>   // filler obj will extend to next region.
>> 
>>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>>   if (UseCompactObjectHeaders) {
>>     // The gap is always equal to min-fill-size, so nothing to do.
>>     return;
>>   }
>>   assert(CollectedHeap::min_fill_size() >= 2, "inv");
>
> Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up.

Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789797050

From stefank at openjdk.org  Mon Oct  7 08:55:59 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 08:55:59 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v9]
In-Reply-To: <CKaxMvoxrt7YLGw6Zee_SW8uBb8tg3j94mw-Mcf5u0I=.78240440-cee1-413b-ae49-1b85592d5ba7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <6Rant6SjxpFIHHWNthWc_plOdnGpWPvqj3rxRe144po=.bcdbad7a-e93a-41a3-b958-6ae602c7e083@github.com>
 <NR6CKOtdUaVarB7hiAUIAsIMe03qiTQr5VcEOWGt8mA=.164efc10-f0ff-4ddf-80b8-c56599c0ba7d@github.com>
 <BNQiyA0NCBO-oFZU4Nz3yvaMxDzICFxfqDKWt4wCL_U=.9405414d-f961-4168-8d26-ef5f58069161@github.com>
 <igBchd3diNsHdnQwZS2sj4tjaKejOq4f4EZovOmpmRQ=.abf79fee-9592-4555-ac01-de0170665ae4@github.com>
 <BkuKSFHleaF8I2tWCDIC-rGlWnfGhbK1zQ6CLlB-rVE=.9c7976e3-b0e9-4356-8d4b-d880aa30bffa@github.com>
 <ubcY5Q-aPRCLmhZV9MjBfzzbs84FegDvNkHx8nwPUd0=.46503fd8-d274-4558-bd0f-cc0c4f199667@github.com>
 <2w9H6VAbxm7BgSGRwKAxbI56bG-k4bE_ZDviGrBF36o=.3d4cb47f-0f84-479a-a809-6d0186dfad2d@github.com>
 <CKaxMvoxrt7YLGw6Zee_SW8uBb8tg3j94mw-Mcf5u0I=.78240440-cee1-413b-ae49-1b85592d5ba7@github.com>
Message-ID: <Hp2zrxh4JHI6OyCJY-KW30h6Tjxj5JeGAinxVNrE8wc=.abaa66fc-cfa8-429a-a179-d6e8075a55ac@github.com>

On Fri, 27 Sep 2024 16:31:55 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This is my current work-in-progress code:
>> https://github.com/stefank/jdk/compare/pull/20677...stefank:jdk:lilliput_remove_prototype_header_wip_2
>> 
>> I've made some large rewrites and I'm currently running it through functional testing.
>
> If @stefank 's patch does not go in this PR, could you please export `Klass::_prototype_header` to JVMCI? Thanks!
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 9d1b8a1cb9f..e462025074f 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -278,6 +278,7 @@
>    nonstatic_field(Klass,                       _bitmap,                                       uintx)                                 \
>    nonstatic_field(Klass,                       _hash_slot,                                    uint8_t)                               \
>    nonstatic_field(Klass,                       _misc_flags._flags,                            u1)                                    \
> +  nonstatic_field(Klass,                       _prototype_header,                             markWord)                              \
>                                                                                                                                       \
>    nonstatic_field(LocalVariableTableElement,   start_bci,                                     u2)                                    \
>    nonstatic_field(LocalVariableTableElement,   length,                                        u2)                                    \

My patch will not be included in this PR. After JEP 450 has been delivered we'll reconsider if we want that patch or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1778950736

From duke at openjdk.org  Mon Oct  7 09:10:52 2024
From: duke at openjdk.org (=?UTF-8?B?QW50w7Nu?= Seoane)
Date: Mon, 7 Oct 2024 09:10:52 GMT
Subject: RFR: 8340363: Tag-specific default decorators for UnifiedLogging
 [v4]
In-Reply-To: <V_Mh3J-trnmVD1y1uQ3sRrAs45kJmInIipq_1BjaHLM=.d9738414-1e7d-4768-8761-6ee56d3aa70d@github.com>
References: <4VEAQafvKlq5O7kpfHcfI9RBfV83zcIwTFe1RyUiKMs=.2af26609-4594-4f98-841c-ca7a56d23271@github.com>
 <V_Mh3J-trnmVD1y1uQ3sRrAs45kJmInIipq_1BjaHLM=.d9738414-1e7d-4768-8761-6ee56d3aa70d@github.com>
Message-ID: <-VhlbMrk05I4TJjr4U_ejcmX02d8ywyaUyQlv8diCHE=.ccd4b85a-3cd4-4f04-95a0-ae9dd59a8c0f@github.com>

On Tue, 24 Sep 2024 16:43:57 GMT, Ant?n Seoane <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, the Unified Logging framework defaults to three decorators (uptime, level, tags) whenever the user does not specify otherwise through `-Xlog`. This can result in cumbersome input whenever a specific user that relies on a particular tag(s) has some predefined needs. For example, C2 developers rarely need decorations, and having to manually specify this every time results inconvenient.
>> 
>> To address this, this PR enables the possibility of adding tag-specific default decorators to UL. These defaults are in no way overriding user input -- they will only act whenever `-Xlog` has no decorators supplied and there is a positive match with the pre-specified defaults. Such a match is based on the following:
>> 
>> - Inclusion: if `-Xlog:jit+compilation` is provided, a default for `jit` may be applied.
>> - Specificity: if, for the above line, there is a more specific default for `jit+compilation` the latter shall be applied. Upon equal specificity cases, both defaults will be applied.
>> - Additionally, defaults may target a specific log level.
>> 
>> Decorators are also associated with an output file, so an output device may only have one set of decorators. For this reason, if different `LogSelection`s trigger defaults, none is to be applied.
>> 
>> In summary, these defaults may be seen as a "tailored" or "flavoured" version of the existing "uptime-level-tags" current defaults.
>> 
>> Please consider this PR, and thanks!
>
> Ant?n Seoane has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed whitespace

After some review and discussion, I am closing this PR and opening a new (simplified) version of this that aligns with the needed use cases in [8341622: Tag-specific disabled default decorators for UnifiedLogging](https://github.com/openjdk/jdk/pull/21383).

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

PR Comment: https://git.openjdk.org/jdk/pull/20988#issuecomment-2396352901

From duke at openjdk.org  Mon Oct  7 09:10:52 2024
From: duke at openjdk.org (=?UTF-8?B?QW50w7Nu?= Seoane)
Date: Mon, 7 Oct 2024 09:10:52 GMT
Subject: Withdrawn: 8340363: Tag-specific default decorators for UnifiedLogging
In-Reply-To: <4VEAQafvKlq5O7kpfHcfI9RBfV83zcIwTFe1RyUiKMs=.2af26609-4594-4f98-841c-ca7a56d23271@github.com>
References: <4VEAQafvKlq5O7kpfHcfI9RBfV83zcIwTFe1RyUiKMs=.2af26609-4594-4f98-841c-ca7a56d23271@github.com>
Message-ID: <6FI0_lFOFEAktdR8fDEyglCSi_mL_zZv8QJdDvTJ5L8=.e0a68b15-9677-48df-8b0a-f263b2357bc5@github.com>

On Fri, 13 Sep 2024 09:03:55 GMT, Ant?n Seoane <duke at openjdk.org> wrote:

> Hi all,
> 
> Currently, the Unified Logging framework defaults to three decorators (uptime, level, tags) whenever the user does not specify otherwise through `-Xlog`. This can result in cumbersome input whenever a specific user that relies on a particular tag(s) has some predefined needs. For example, C2 developers rarely need decorations, and having to manually specify this every time results inconvenient.
> 
> To address this, this PR enables the possibility of adding tag-specific default decorators to UL. These defaults are in no way overriding user input -- they will only act whenever `-Xlog` has no decorators supplied and there is a positive match with the pre-specified defaults. Such a match is based on the following:
> 
> - Inclusion: if `-Xlog:jit+compilation` is provided, a default for `jit` may be applied.
> - Specificity: if, for the above line, there is a more specific default for `jit+compilation` the latter shall be applied. Upon equal specificity cases, both defaults will be applied.
> - Additionally, defaults may target a specific log level.
> 
> Decorators are also associated with an output file, so an output device may only have one set of decorators. For this reason, if different `LogSelection`s trigger defaults, none is to be applied.
> 
> In summary, these defaults may be seen as a "tailored" or "flavoured" version of the existing "uptime-level-tags" current defaults.
> 
> Please consider this PR, and thanks!

This pull request has been closed without being integrated.

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

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

From rkennke at openjdk.org  Mon Oct  7 10:52:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 10:52:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
Message-ID: <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>

On Mon, 7 Oct 2024 08:49:58 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Style note: The added code is inserted between a comment and the code that the comment refers to. It would be nice to tidy this up.
>
> Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?

When MinObjectAlignment=16, then that method does nothing anyway:


  if (MinObjAlignment > 1) {
    return;
  }



I think what it really means to say is

  if (MinObjAlignment >=  CollectedHeap::min_fill_size()) {
    return;
  }



That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."

If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.

I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789983561

From rkennke at openjdk.org  Mon Oct  7 11:03:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 11:03:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
 <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
Message-ID: <wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>

On Mon, 7 Oct 2024 08:25:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>> 
>>  - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>>    
>>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>>  - Simplify object init code in interpreter
>>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>>  - Fix for CDSPluginTest.java
>>  - Merge tag 'jdk-24+18' into JDK-8305895-v4
>>    
>>    Added tag jdk-24+18 for changeset 19642bd3
>>  - Disable TestSplitPacks::test4a, failing on aarch64
>>  - @robcasloz review comments
>>  - Improve CollectedHeap::is_oop()
>>  - Allow LM_MONITOR on 32-bit platforms
>>  - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
>
> src/hotspot/share/oops/compressedKlass.cpp line 28:
> 
>> 26: #include "logging/log.hpp"
>> 27: #include "memory/metaspace.hpp"
>> 28: #include "oops/klass.hpp"
> 
> Is this include really needed or could this be reverted klass.hpp? If it is needed is should be moved to after compressedKlass.inline.hpp.

I don't think it's needed. I'll remove it.

> src/hotspot/share/oops/compressedKlass.cpp line 31:
> 
>> 29: #include "oops/compressedKlass.inline.hpp"
>> 30: #include "runtime/globals.hpp"
>> 31: #include "runtime/java.hpp"
> 
> Do you remember why this was added?

Looks like this is for vm_exit_during_initialization().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789996985
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1789999402

From stefank at openjdk.org  Mon Oct  7 11:43:00 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 11:43:00 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
 <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
 <wZQvls5Bmb1p4U0LFvXishmbr_J18_Il1tDQVbiAolk=.d26b761e-3201-44b8-8b62-aa0cf4dd32ed@github.com>
Message-ID: <xkj4iPPqe3T_nJxW_IE59EF806ZEA4cbXZNphRCmYLQ=.5e23dced-9aa6-418c-bfd5-2aad3b727a68@github.com>

On Mon, 7 Oct 2024 11:00:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 31:
>> 
>>> 29: #include "oops/compressedKlass.inline.hpp"
>>> 30: #include "runtime/globals.hpp"
>>> 31: #include "runtime/java.hpp"
>> 
>> Do you remember why this was added?
>
> Looks like this is for vm_exit_during_initialization().

I see. Thanks. (What a funny header file that is)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790060417

From stefank at openjdk.org  Mon Oct  7 11:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 7 Oct 2024 11:51:54 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
 <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
Message-ID: <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>

On Mon, 7 Oct 2024 10:49:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Did you figure out if the code above is correct w.r.t. `MinObjectAlignment=16`?
>
> When MinObjectAlignment=16, then that method does nothing anyway:
> 
> 
>   if (MinObjAlignment > 1) {
>     return;
>   }
> 
> 
> 
> I think what it really means to say is
> 
>   if (MinObjAlignment >=  CollectedHeap::min_fill_size()) {
>     return;
>   }
> 
> 
> 
> That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."
> 
> If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.
> 
> I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.

After re-reading this again I agree with what you're writing. If you make the change to use:

if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
 return;
 }


do you even have to check for UCOH in this function?

I also wonder if you could tweak the comment now that this is not true when UCOH is on:

// The size of the filler (min-obj-size) is 2 heap words with the default
// MinObjAlignment, since both markword and klass take 1 heap word.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790074043

From jbechberger at openjdk.org  Mon Oct  7 11:54:04 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 7 Oct 2024 11:54:04 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent
Message-ID: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>

Remove the support for on-demand debugging via the onjcmd option.

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

Commit messages:
 - Remove added empty line
 - Fix AgentEvent test
 - Remove onjcmd

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

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

From kevinw at openjdk.org  Mon Oct  7 12:00:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Oct 2024 12:00:37 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run
In-Reply-To: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
Message-ID: <88IVcbLd9mJnbF_d2UZSSdcJPf50KTXhliVo7cUjU8M=.6596df82-eaf1-4830-b439-e72cb7e4fda2@github.com>

On Thu, 3 Oct 2024 19:13:46 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> The fix is twofold.
> 
> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
> 
> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
> 
> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
> 
> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
> 
> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
> 
> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.

Hi, I think this looks good.
Having main container name be unique is good.  Do you just add "elevated-" + elevated here, it would be great to add even a random ID in there as well, as we can have multiple tests running on the same machine at times...

The other problem ( https://bugs.openjdk.org/browse/JDK-8341518 ) seems to be EventGeneratorLoop terminating too early, we have some logs where it's gone after 10 or 12 seconds, not 120.  It should maybe check a wall-clock time to ensure it lives long enough.  I can do that separately unless you think it makes sense to include it here, I don't think it will conflict.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2396725847

From rkennke at openjdk.org  Mon Oct  7 12:48:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 12:48:43 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v31]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <zFKBeHSnUUhfCv95M3aVKEFRTEcEn_m5iS69tohiAsE=.b652f8fd-9da1-4428-8488-57c06f275da9@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  @stefank review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/8742f3c1..572f1ac0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=29-30

  Stats: 20 lines in 6 files changed: 4 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Mon Oct  7 13:24:26 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:24:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v32]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <XdTIEoeBMhkUPVI42RfZLH-PP6QszZ66_FeCrqDtxs0=.3da42b45-52af-4c75-a01e-6df7c81ab9db@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/572f1ac0..60401086

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=30-31

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

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

From rkennke at openjdk.org  Mon Oct  7 13:32:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:32:41 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v2]
In-Reply-To: <BneyQG9faYqRCvUeqGbfun-y4bno0I4KR15685D0gZ0=.94c5052d-cb02-40d2-b158-f3c9d85ceffc@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <BneyQG9faYqRCvUeqGbfun-y4bno0I4KR15685D0gZ0=.94c5052d-cb02-40d2-b158-f3c9d85ceffc@github.com>
Message-ID: <E7tz6jf5RnfpORFkTiDwjvglAPtoW0zH_dt8lUGvyEs=.3d17aa5f-d51b-44af-8496-48722ad543f8@github.com>

On Fri, 4 Oct 2024 18:21:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper 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 475 additional commits since the last revision:
> 
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - Merge
>  - 8339643: Port JEP 404 to RISC-V
>    
>    Reviewed-by: wkemper, kdnilsen
>  - 8340395: GenShen: Remove unnecessary check on card barrier flag
>    
>    Reviewed-by: ysr
>  - ... and 465 more: https://git.openjdk.org/jdk/compare/e155dc3e...ed16e3ec

There seems to be something missing:

/home/runner/work/jdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp: In member function ?oop ShenandoahHeap::try_evacuate_object(oop, Thread*, ShenandoahHeapRegion*, ShenandoahAffiliation)?:
/home/runner/work/jdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:1276:3: error: ?_evac_tracker? was not declared in this scope; did you mean ?_mmu_tracker??
 1276 |   _evac_tracker->begin_evacuation(thread, size * HeapWordSize);
      |   ^~~~~~~~~~~~~
      |   _mmu_tracker
/home/runner/work/jdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp: In member function ?virtual void ShenandoahHeap::print_tracing_info() const?:
/home/runner/work/jdk/jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:1534:5: error: ?evac_tracker? was not declared in this scope; did you mean ?mmu_tracker??
 1534 |     evac_tracker()->print_global_on(&ls);
      |     ^~~~~~~~~~~~
      |     mmu_tracker

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

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2396941518

From rkennke at openjdk.org  Mon Oct  7 13:55:17 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:55:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v33]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <VWBPrwk40VzajxZ4gNqUF-w3-XkNWyCK1ayQ7TFYxNs=.1e941ed0-5dad-4321-bcd5-1c87517f3aa6@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rename nklass/nKlass

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/60401086..1ab20774

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=31-32

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

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

From rkennke at openjdk.org  Mon Oct  7 13:55:18 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 13:55:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v30]
In-Reply-To: <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <aU7Oq51P0gFTm6hW7hQW_fmAYCdLG6JlqW6lBOkaRKE=.e30fa902-dc09-4944-8983-2c14ad068cf1@github.com>
 <NtlirWYS-adgUWyhc0RA52WzClmcbtRuk3ykReYfsDg=.db48cc39-e30d-49e2-8a61-df4f40ecf73b@github.com>
Message-ID: <gW425l3Fk9V3WAGejgKf-PunT7yc2abszhJiU7L1jJw=.6704865f-b06e-4f0d-8637-08d66422c8b9@github.com>

On Mon, 7 Oct 2024 08:44:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 76 commits:
>> 
>>  - Merge remote-tracking branch 'rkennke/JDK-8305895-v4' into JDK-8305895-v4
>>  - Revert "Disable TestSplitPacks::test4a, failing on aarch64"
>>    
>>    This reverts commit 059b1573db26d1d2902ca6dadc8413f445234c2a.
>>  - Simplify object init code in interpreter
>>  - Disable some vectorization tests that fail with +UCOH and UseSSE<=3
>>  - Fix for CDSPluginTest.java
>>  - Merge tag 'jdk-24+18' into JDK-8305895-v4
>>    
>>    Added tag jdk-24+18 for changeset 19642bd3
>>  - Disable TestSplitPacks::test4a, failing on aarch64
>>  - @robcasloz review comments
>>  - Improve CollectedHeap::is_oop()
>>  - Allow LM_MONITOR on 32-bit platforms
>>  - ... and 66 more: https://git.openjdk.org/jdk/compare/19642bd3...8742f3c1
>
> src/hotspot/share/oops/markWord.cpp line 35:
> 
>> 33: STATIC_ASSERT(markWord::klass_shift + markWord::klass_bits == 64);
>> 34: // The hash (preceding nKlass) shall be a direct neighbor but not interleave
>> 35: STATIC_ASSERT(markWord::klass_shift == markWord::hash_bits + markWord::hash_shift);
> 
> The code is not consistent in it usage of the name for the klass bits. Here it says `nKlass` in the comment, but the fields are named `klass`. Maybe just change the comment to says `(preceding klass bits)`.
> 
> Note that the term `nklass` is not prevalent in the code base, but with this patch its starting to get a foot hold. It might be good to figure out what we do want to call these in field names and variables to at least a little bit more consistency in the code base. Currently we have `nklass`, `nKlass` `nk`, `narrow_klass`.
> 
>  In other places we have functions that are named `set_narrow_klass`, but the field is called `nklass` and other places call it `nk`. It would be good to stay consistent with the naming. FWIW, nklass has very little precedence in the code, so cleaning that away might be easiest.thing is to clean out all usages of nklass, because it isn't a

I renamed all occurrences of nklass and nKlass in shared code to something more useful. I left load_nklass* stuff in aarch64 and x86 code alone for now. Let me know if that addresses your concern.

https://github.com/openjdk/jdk/pull/20677/commits/1ab207746e4c4baaa6da162d7c1535c75342fa2e

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790270819

From rkennke at openjdk.org  Mon Oct  7 14:28:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 7 Oct 2024 14:28:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v34]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <jg_gzL1xUQxh6Isj-q5ceTJf4r9UM7CvHWlyoT3H_Ok=.314a0607-2bbe-42c8-b9c3-b5e8c8efb110@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Some more review comments/cleanups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1ab20774..17f8eb54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=32-33

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

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

From cjplummer at openjdk.org  Mon Oct  7 16:20:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 7 Oct 2024 16:20:36 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent
In-Reply-To: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
Message-ID: <4vmUQq_JI__RMxhSejCEjtYHtCWgNgALCygYx0fwXyM=.5e8bca4d-1ef6-4016-abd6-ef0e4dd38adc@github.com>

On Mon, 7 Oct 2024 11:47:12 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Remove the support for on-demand debugging via the onjcmd option.

test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java line 68:

> 66:  *      testJavaDynamic
> 67:  *
> 68:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=:5005

This use of port 5005 could possibly conflict with other tests running in parallel that were already dynamically assigned this port. Is there a reason it can't remain "any"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21387#discussion_r1790525765

From rsunderbabu at openjdk.org  Mon Oct  7 16:40:14 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 7 Oct 2024 16:40:14 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging
Message-ID: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>

JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.

Testing:
tier1,tier2,tier3
tier6-comp,tier8-comp

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

Commit messages:
 - initial commit

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

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

From kevinw at openjdk.org  Mon Oct  7 16:57:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Oct 2024 16:57:35 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging
In-Reply-To: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
Message-ID: <AERyYZLlHnhJVpyBsL2TdByEBi3u0rkk37cRL92X0A0=.d4e466fe-9e46-4ead-8213-db6592b8e4dd@github.com>

On Mon, 7 Oct 2024 15:28:19 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
> 
> Testing:
> tier1,tier2,tier3
> tier6-comp,tier8-comp

Looks good, let's try it!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21392#pullrequestreview-2352488029

From jbechberger at openjdk.org  Mon Oct  7 18:53:41 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 7 Oct 2024 18:53:41 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent
In-Reply-To: <4vmUQq_JI__RMxhSejCEjtYHtCWgNgALCygYx0fwXyM=.5e8bca4d-1ef6-4016-abd6-ef0e4dd38adc@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
 <4vmUQq_JI__RMxhSejCEjtYHtCWgNgALCygYx0fwXyM=.5e8bca4d-1ef6-4016-abd6-ef0e4dd38adc@github.com>
Message-ID: <df5DDU_g5wL7YShZ3iIBt0NGI9GS4E6k2wgqXPuMwSo=.849db006-74e3-4839-a4c7-cade64e492f0@github.com>

On Mon, 7 Oct 2024 16:17:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Remove the support for on-demand debugging via the onjcmd option.
>
> test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java line 68:
> 
>> 66:  *      testJavaDynamic
>> 67:  *
>> 68:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=:5005
> 
> This use of port 5005 could possibly conflict with other tests running in parallel that were already dynamically assigned this port. Is there a reason it can't remain "any"?

Good catch, I'll try using `any` tomorrow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21387#discussion_r1790719642

From duke at openjdk.org  Mon Oct  7 19:23:58 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 7 Oct 2024 19:23:58 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v2]
In-Reply-To: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
Message-ID: <IrFEdno0awMyJIRrthSPMxVGEVCpiAbPeTsP-M2sZZQ=.38f2c332-2e6a-4999-b561-99376d6bb321@github.com>

> The fix is twofold.
> 
> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
> 
> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
> 
> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
> 
> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
> 
> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
> 
> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.

Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:

  Append random integer to container name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21331/files
  - new: https://git.openjdk.org/jdk/pull/21331/files/448455c2..b7e0480c

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

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

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

From duke at openjdk.org  Mon Oct  7 19:23:58 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 7 Oct 2024 19:23:58 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run
In-Reply-To: <88IVcbLd9mJnbF_d2UZSSdcJPf50KTXhliVo7cUjU8M=.6596df82-eaf1-4830-b439-e72cb7e4fda2@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <88IVcbLd9mJnbF_d2UZSSdcJPf50KTXhliVo7cUjU8M=.6596df82-eaf1-4830-b439-e72cb7e4fda2@github.com>
Message-ID: <VOUXfIlAjkOnvddrjtJAUBqf8QRJ67hgnhNgKthae-8=.2311cff8-43ce-4e0e-bf89-c306b2792396@github.com>

On Mon, 7 Oct 2024 11:57:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Hi, I think this looks good.
> Having main container name be unique is good.  Do you just add "elevated-" + elevated here, it would be great to add even a random ID in there as well, as we can have multiple tests running on the same machine at times...
> 
> The other problem ( https://bugs.openjdk.org/browse/JDK-8341518 ) seems to be EventGeneratorLoop terminating too early, we have some logs where it's gone after 10 or 12 seconds, not 120.  It should maybe check a wall-clock time to ensure it lives long enough.  I can do that separately unless you think it makes sense to include it here, I don't think it will conflict.

Thanks for taking a look, @kevinjwalls!

>  Having main container name be unique is good. Do you just add "elevated-" + elevated here, it would be great to add even a random ID in there as well, as we can have multiple tests running on the same machine at times...

Sounds good. The thought did cross my mind, but I decided to skip it anyway. Adding it in b7e0480c421c77cf240e2ce2c24a810dd65908f6.

> The other problem ( https://bugs.openjdk.org/browse/JDK-8341518 ) seems to be EventGeneratorLoop terminating too early, we have some logs where it's gone after 10 or 12 seconds, not 120. It should maybe check a wall-clock time to ensure it lives long enough. I can do that separately unless you think it makes sense to include it here, I don't think it will conflict.

Interesting! What could possibly interrupt `EventGeneratorLoop`?

I don't mind adding it here, I'll take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2397704133

From duke at openjdk.org  Mon Oct  7 19:37:51 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 7 Oct 2024 19:37:51 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
Message-ID: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>

> The fix is twofold.
> 
> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
> 
> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
> 
> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
> 
> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
> 
> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
> 
> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.

Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:

  Have EventGeneratorLoop end after a more predictable duration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21331/files
  - new: https://git.openjdk.org/jdk/pull/21331/files/b7e0480c..cdf92697

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

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

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

From kevinw at openjdk.org  Mon Oct  7 19:42:35 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Oct 2024 19:42:35 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run
In-Reply-To: <VOUXfIlAjkOnvddrjtJAUBqf8QRJ67hgnhNgKthae-8=.2311cff8-43ce-4e0e-bf89-c306b2792396@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <88IVcbLd9mJnbF_d2UZSSdcJPf50KTXhliVo7cUjU8M=.6596df82-eaf1-4830-b439-e72cb7e4fda2@github.com>
 <VOUXfIlAjkOnvddrjtJAUBqf8QRJ67hgnhNgKthae-8=.2311cff8-43ce-4e0e-bf89-c306b2792396@github.com>
Message-ID: <KRRNVKZKQfmAQ97b8WIQQ4GEi5fah6tvdjY74WGIxrU=.07186195-1bf3-43f6-af5d-0c7940010c5b@github.com>

On Mon, 7 Oct 2024 19:20:38 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

> Interesting! What could possibly interrupt `EventGeneratorLoop`?

It's a good question, but I don't know exactly...  We do see interrupted exceptions in testing sometimes, and we might have various tests running on the same system at the same time.  The tests which attach or otherwise poke around and look at other processes can be part of the problem, but I don't have a particular test in mind.  So I'm thinking we can be defensive...

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2397739522

From duke at openjdk.org  Mon Oct  7 19:42:37 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 7 Oct 2024 19:42:37 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <vk128tyUdV1J51XzRp5KYWMxorO5JYEX13fn_kvIg74=.b79e33df-687b-4c2c-8ad7-4499384f5446@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

test/hotspot/jtreg/containers/docker/EventGeneratorLoop.java line 58:

> 56:             ev.msg = "Hello";
> 57:             ev.count = count++;
> 58:             ev.commit();

@kevinjwalls what do you think? I chose `System.nanoTime()` instead of `System.currentTimeMillis()` to get an even more predictable duration. 

Before this change, `EventGeneratorLoop` was guaranteed to post the same number of events as the input argument. It no longer is, but AFAICT no current test uses the events it posts either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21331#discussion_r1790777201

From kevinw at openjdk.org  Mon Oct  7 19:46:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Oct 2024 19:46:37 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <Bm2ijFwXjFrR8esBbUqCbJudzHiTFV67K0cnQ5eCh0Q=.432bc7c6-d3a4-4e57-983c-71467b93ad8a@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

Thanks yes that looks good to me.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21331#pullrequestreview-2352796003

From duke at openjdk.org  Mon Oct  7 19:49:36 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Mon, 7 Oct 2024 19:49:36 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <ols57Lj0MhX_ABRDW-ri6iTGsvua-Rn5js4_xvu6Iac=.e1e8d4fb-d961-4586-91f4-dedd1f24cec0@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

Thanks for the quick check! Let's hope this solves JDK-8341518 too. Should I add JDK-8341518 to this PR so it gets closed as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2397753746

From kevinw at openjdk.org  Mon Oct  7 19:53:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Oct 2024 19:53:37 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <oYAgmExlC9HBh_gFZwAUVG9wGv53BubUYQJfkMEvXKk=.4a4ecd19-a3dd-4e15-b751-d1838de69e3a@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

Don't worry I'll close 8341518  as a duplicate.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2397760581

From duke at openjdk.org  Mon Oct  7 19:56:35 2024
From: duke at openjdk.org (duke)
Date: Mon, 7 Oct 2024 19:56:35 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <rQqqv6nS6oSUEpqAvWTRGNRD9riJA3DgeNyzGucyvJ4=.bcec619e-b201-4ffd-b312-035d38ffab46@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

@slovdahl 
Your change (at version cdf92697b4e9bf6c47138db38e9c2cd22ddf558f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2397766398

From sspitsyn at openjdk.org  Mon Oct  7 22:32:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Oct 2024 22:32:55 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <p7k__WSzVED_67foMGXVosUeTO_oPgQEcTjd6D4vPiY=.e5fd7e5a-12c4-4d47-8757-0c23085d7ec6@github.com>

On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

The frames which are in VTMS transition should not be visible to the JVMTI agents including debug agent because the thread identity can be incorrect. The JVMTI events are not posted when `java_thread->is_in_VTMS_transition() == true`.
All the JVMTI functions returning stack related info do skip frames that are in transition. The hiding mechanism is using the annotation `@JvmtiMountTransition` to mark the `notifyJvmti*` methods and the bit `java_thread->is_in_VTMS_transition()`.
It occurred that the methods `yield()` and `yield0()` can be present in stack trace of an unmounted virtual threads.
The bit `java_thread->is_in_VTMS_transition() ` is not set in such a case.
The fix is to add the annotation `@JvmtiMountTransition` to the methods `yield()` and `yield0()` and correct the frames skipping mechanism to account for such frames as well.
The update also includes:
 - fix in one of the `JvmtiHandshake::execute()` functions which is needed for better stability and safety
 - tweak in the test which expects frames with `yield()` and `yield0()` methods to be present at the top

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

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2398025342

From sspitsyn at openjdk.org  Mon Oct  7 22:32:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 7 Oct 2024 22:32:55 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation related
 methods
Message-ID: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>

This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
Please, see a fix description in the first comment.

Testing:
 - Verified with new test `vthread/CheckHiddenFrames`
 - Mach5 tiers 1-6 are passed

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

Commit messages:
 - fix one more place with trailing spaces
 - fix trailing spaces
 - add new test coverage with  vthread/CheckHiddenFrames
 - 8341273: JVMTI is not properly hiding some continuation related methods

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

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

From sviswanathan at openjdk.org  Mon Oct  7 22:43:15 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 7 Oct 2024 22:43:15 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
Message-ID: <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>

On Fri, 4 Oct 2024 10:41:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @rkennke The small loop looks to me that it will run over the end of the array.
>> Say the haystack_len is 7, the index below would be 0 after the shrq instruction, and the  movq(XMM_TMP1, Address(haystack, index, Address::times_8)) in the loop will read 8 bytes i.e. one byte past the end of the array:
>>        // num_words (zero-based) = (haystack_len - 1) / 8;
>>       __ movq(index, haystack_len);
>>       __ subq(index, 1);
>>       __ shrq(index, LogBytesPerWord);
>> 
>>       __ bind(L_loop);
>>       __ movq(XMM_TMP1, Address(haystack, index, Address::times_8));
>>       __ movq(Address(rsp, index, Address::times_8), XMM_TMP1);
>>       __ subq(index, 1);
>>       __ jcc(Assembler::positive, L_loop);
>
> Yes, and that is intentional.
> 
> Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.
> 
> Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.
> 
> Then comes the actual loop.
> 
> Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.

@rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places. 
[indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1790967275

From lmesnik at openjdk.org  Tue Oct  8 00:13:58 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 8 Oct 2024 00:13:58 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>

On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Changes requested by lmesnik (Reviewer).

src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:

> 689: 
> 690:   if (is_virtual || jt->is_in_VTMS_transition()) { // filter out pure continuations
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);

Wouldn't be easier to split method `check_and_skip_hidden_frames` to skip_yeilds and skip_transition frames? 
BTW Also it is unclear shouldn't the `@Hidden` methods be skipped from all jvmti frame streams?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2009:

> 2007:   bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
> 2008: 
> 2009:   // Target can be virtual or platform thread.

Can you please explain in comment why is it needed to disable all threads for platform target thread.

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 25:

> 23: 
> 24: /*
> 25:  * @test id=virtual

Having 'id=virtual' not needed and might confuse people. They expect to have other test variations for platform.

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 32:

> 30: 
> 31: public class CheckHiddenFrames {
> 32:     private static final String AGENT_LIB = "CheckHiddenFrames";

It is not used?

test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 43:

> 41: 
> 42:     public static void main(String[] args) throws Exception {
> 43:         Thread thread = Thread.ofVirtual().unstarted(CheckHiddenFrames::test);

You can use 
startVirtualThread
to save one line.

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

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2353060666
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1791023030
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1791008060
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790967726
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790968113
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1790966876

From rsunderbabu at openjdk.org  Tue Oct  8 01:16:46 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 8 Oct 2024 01:16:46 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v2]
In-Reply-To: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
Message-ID: <1TOhcDrLuyZyDYYqR1h5Prhr-vKvkfcYaAe7_O9oLEg=.3eb3ef39-339d-4154-a5c2-2072d5a092e9@github.com>

> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
> 
> Testing:
> tier1,tier2,tier3
> tier6-comp,tier8-comp

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

  resolving merge conflict

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21392/files
  - new: https://git.openjdk.org/jdk/pull/21392/files/897ba0f7..04546b5d

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

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

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

From lmesnik at openjdk.org  Tue Oct  8 02:06:57 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 8 Oct 2024 02:06:57 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v2]
In-Reply-To: <1TOhcDrLuyZyDYYqR1h5Prhr-vKvkfcYaAe7_O9oLEg=.3eb3ef39-339d-4154-a5c2-2072d5a092e9@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
 <1TOhcDrLuyZyDYYqR1h5Prhr-vKvkfcYaAe7_O9oLEg=.3eb3ef39-339d-4154-a5c2-2072d5a092e9@github.com>
Message-ID: <OedMhielTpILx5y5JfeJDnRKJHfn9o66msQmDYq7r6g=.f7d007dc-ed5a-469e-8297-16ee3afc4564@github.com>

On Tue, 8 Oct 2024 01:16:46 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
>> 
>> Testing:
>> tier1,tier2,tier3
>> tier6-comp,tier8-comp
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   resolving merge conflict

Changes requested by lmesnik (Reviewer).

test/jdk/ProblemList-Xcomp.txt line 31:

> 29: 
> 30: java/lang/invoke/MethodHandles/CatchExceptionTest.java          8146623 generic-all
> 31: java/foreign/TestUpcallStress.java                              8341584 generic-all

This looks odd, this line shouldn't be added with your PR. It makes history of commits wrong. Please check if it was correctly merged.

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

PR Review: https://git.openjdk.org/jdk/pull/21392#pullrequestreview-2353223223
PR Review Comment: https://git.openjdk.org/jdk/pull/21392#discussion_r1791080538

From rsunderbabu at openjdk.org  Tue Oct  8 02:31:08 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 8 Oct 2024 02:31:08 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v2]
In-Reply-To: <OedMhielTpILx5y5JfeJDnRKJHfn9o66msQmDYq7r6g=.f7d007dc-ed5a-469e-8297-16ee3afc4564@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
 <1TOhcDrLuyZyDYYqR1h5Prhr-vKvkfcYaAe7_O9oLEg=.3eb3ef39-339d-4154-a5c2-2072d5a092e9@github.com>
 <OedMhielTpILx5y5JfeJDnRKJHfn9o66msQmDYq7r6g=.f7d007dc-ed5a-469e-8297-16ee3afc4564@github.com>
Message-ID: <FbiEL-FhokCZKktgnMWO8n6xi_BYHkiD4Hz7VUN84bE=.ddb21b6b-0274-46c9-8560-e0efb66e9db5@github.com>

On Tue, 8 Oct 2024 02:03:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   resolving merge conflict
>
> test/jdk/ProblemList-Xcomp.txt line 31:
> 
>> 29: 
>> 30: java/lang/invoke/MethodHandles/CatchExceptionTest.java          8146623 generic-all
>> 31: java/foreign/TestUpcallStress.java                              8341584 generic-all
> 
> This looks odd, this line shouldn't be added with your PR. It makes history of commits wrong. Please check if it was correctly merged.

Yeah, I messed up while resolving conflicts. I am checking how to correct this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21392#discussion_r1791094005

From rsunderbabu at openjdk.org  Tue Oct  8 04:17:31 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 8 Oct 2024 04:17:31 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v3]
In-Reply-To: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
Message-ID: <OpcyS1wvmg0lm_w0HFX5wZPj2r-FtXKNuySFu--PbPQ=.cc126ac2-d302-465a-8b5c-f1188ca35722@github.com>

> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
> 
> Testing:
> tier1,tier2,tier3
> tier6-comp,tier8-comp

Ramkumar Sunderbabu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  commit after resolving conflicts

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

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

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

From lmesnik at openjdk.org  Tue Oct  8 04:32:57 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 8 Oct 2024 04:32:57 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v3]
In-Reply-To: <OpcyS1wvmg0lm_w0HFX5wZPj2r-FtXKNuySFu--PbPQ=.cc126ac2-d302-465a-8b5c-f1188ca35722@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
 <OpcyS1wvmg0lm_w0HFX5wZPj2r-FtXKNuySFu--PbPQ=.cc126ac2-d302-465a-8b5c-f1188ca35722@github.com>
Message-ID: <b0-BX-lJowKWLNd9eBqHOUcyLQtkz7HwB4lqFAtYjS0=.eb4d2b27-d27b-43da-80e8-c6aa3a67d7f5@github.com>

On Tue, 8 Oct 2024 04:17:31 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
>> 
>> Testing:
>> tier1,tier2,tier3
>> tier6-comp,tier8-comp
>
> Ramkumar Sunderbabu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   commit after resolving conflicts

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21392#pullrequestreview-2353346908

From jbechberger at openjdk.org  Tue Oct  8 06:58:13 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 8 Oct 2024 06:58:13 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent [v2]
In-Reply-To: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
Message-ID: <VRrXNAupKWfRz6R603yHDedooupj2bjkLDXt68m9DhQ=.88dfc7bc-2555-490e-b214-87015286fe47@github.com>

> Remove the support for on-demand debugging via the onjcmd option.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Use port 0 in TestAgentEvent

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21387/files
  - new: https://git.openjdk.org/jdk/pull/21387/files/f76f8db0..17b7b5a5

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

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

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

From jbechberger at openjdk.org  Tue Oct  8 06:58:13 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 8 Oct 2024 06:58:13 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent [v2]
In-Reply-To: <4vmUQq_JI__RMxhSejCEjtYHtCWgNgALCygYx0fwXyM=.5e8bca4d-1ef6-4016-abd6-ef0e4dd38adc@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
 <4vmUQq_JI__RMxhSejCEjtYHtCWgNgALCygYx0fwXyM=.5e8bca4d-1ef6-4016-abd6-ef0e4dd38adc@github.com>
Message-ID: <P-1pf1munq4VEW4wbdYIeSSxvMqK0OcZl0ns_swdydE=.efdef254-e075-4b5f-bfa0-a04b67f9b128@github.com>

On Mon, 7 Oct 2024 16:17:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use port 0 in TestAgentEvent
>
> test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java line 68:
> 
>> 66:  *      testJavaDynamic
>> 67:  *
>> 68:  * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=:5005
> 
> This use of port 5005 could possibly conflict with other tests running in parallel that were already dynamically assigned this port. Is there a reason it can't remain "any"?

Using `any` leads to the following error:


ERROR: transport error 103: invalid port number specified
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:700]


This doesn't happen with onjcmd because it delays parsing the port till the debugging is enabled. Using `0` as @schmelter-sap suggested, should prevent any issues.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21387#discussion_r1791299808

From rkennke at openjdk.org  Tue Oct  8 07:08:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:08:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v35]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <0ahBmcWCHqMMxr9RxUlOPgEJy4WSs7lQgRnxtEonZaY=.28275c5d-2d5f-490c-bf39-b0bb6817d6be@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Rename nklass in x86 code
 - Fix header < 16 bytes in indexOf intrinsic, by @sviswa7

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/17f8eb54..4d7228e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=33-34

  Stats: 148 lines in 6 files changed: 84 ins; 47 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Tue Oct  8 07:21:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:21:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v36]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <mPNm6oxqHzUbpQMEvipfe8R-BgbFjrLQm3eXsSHxPxc=.32a33c8f-21bf-4226-8282-352234755d8e@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Re-enable indexOf intrinsic for compact headers
 - Rename nklass in aarch64
 - Fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/4d7228e0..0be2fc40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=34-35

  Stats: 15 lines in 8 files changed: 0 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From rkennke at openjdk.org  Tue Oct  8 07:21:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 07:21:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
Message-ID: <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>

On Mon, 7 Oct 2024 22:40:37 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Yes, and that is intentional.
>> 
>> Say, haystack_len is 7, then the first block computes the adjustment of the haystack, which is 8 - (7 % 8) = 1. We adjust the haystack pointer one byte down, so that when we copy (multiple of) 8 bytes, we land on the last byte. We do copy a few bytes that are preceding the array, which is part of the object header and guaranteed to be >= 8 bytes.
>> 
>> Then we compute the number of words to copy, but make it 0-based. That is '0' is 1 word, '1' is 2 words, etc. It makes the loop nicer. In this example we get 0, which means we copy one word from the adjusted haystack, which is correct.
>> 
>> Then comes the actual loop.
>> 
>> Afterwards we adjust the haystack pointer so that it points to the first array element that we just copied onto the stack, ignoring the few garbage bytes that we also copied.
>
> @rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places. 
> [indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)

Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791328427

From ayang at openjdk.org  Tue Oct  8 07:43:18 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 8 Oct 2024 07:43:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
 <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
 <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
Message-ID: <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>

On Mon, 7 Oct 2024 11:49:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When MinObjectAlignment=16, then that method does nothing anyway:
>> 
>> 
>>   if (MinObjAlignment > 1) {
>>     return;
>>   }
>> 
>> 
>> 
>> I think what it really means to say is
>> 
>>   if (MinObjAlignment >=  CollectedHeap::min_fill_size()) {
>>     return;
>>   }
>> 
>> 
>> 
>> That's also what the comment says: "The size of the gap (if any) right before dense-prefix-end is MinObjAlignment. Need to fill in the gap only if it's smaller than min-obj-size, and the filler obj will extend to next region."
>> 
>> If I interpret that correctly, we need to deal with the situation only when MinObjAlignment < min_fill_size, because the filler object would extend to the next region, and we need to adjust the next region and mark-bitmap for that extra word. @albertnetymk might want to confirm.
>> 
>> I'll move the if (UCOH) block down a little bit to right before if (MinObjAlignment) block.
>
> After re-reading this again I agree with what you're writing. If you make the change to use:
> 
> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
>  return;
>  }
> 
> 
> do you even have to check for UCOH in this function?
> 
> I also wonder if you could tweak the comment now that this is not true when UCOH is on:
> 
> // The size of the filler (min-obj-size) is 2 heap words with the default
> // MinObjAlignment, since both markword and klass take 1 heap word.

I took UCOH into account when this code was written -- the current version of PR would fail the following assert. 


  // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
  assert(CollectedHeap::min_fill_size() >= 2, "inv");


The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791362310

From stefank at openjdk.org  Tue Oct  8 08:15:18 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Oct 2024 08:15:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
 <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
 <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
 <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
Message-ID: <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>

On Tue, 8 Oct 2024 07:40:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> After re-reading this again I agree with what you're writing. If you make the change to use:
>> 
>> if (MinObjAlignment >= CollectedHeap::min_fill_size()) {
>>  return;
>>  }
>> 
>> 
>> do you even have to check for UCOH in this function?
>> 
>> I also wonder if you could tweak the comment now that this is not true when UCOH is on:
>> 
>> // The size of the filler (min-obj-size) is 2 heap words with the default
>> // MinObjAlignment, since both markword and klass take 1 heap word.
>
> I took UCOH into account when this code was written -- the current version of PR would fail the following assert. 
> 
> 
>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>   assert(CollectedHeap::min_fill_size() >= 2, "inv");
> 
> 
> The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.

I was thinking that we should remove the entire:

  // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
  assert(CollectedHeap::min_fill_size() >= 2, "inv");

block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791409345

From rkennke at openjdk.org  Tue Oct  8 10:03:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:03:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v37]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <KrjrTqHnaXCIkD8T2a_EfnjTd0nVgxBD45NN6PeqXQY=.a4249a8f-ef4e-4008-9418-565ecf007c22@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Improve PSParallelCompact::fill_dense_prefix_end() even more

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/0be2fc40..d57dbfc5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=35-36

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

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

From stooke at openjdk.org  Tue Oct  8 10:12:03 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 8 Oct 2024 10:12:03 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v13]
In-Reply-To: <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <DnxU95E6xPzeplFJjqm9uBz9uVtPrabtyBDMHCSY0DA=.96dfd1b4-8464-4c54-8d12-8289260f754e@github.com>
 <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
Message-ID: <ziHQRGmGmnG--VjGr0czmeu2sqg10uOQJCRXmapa_2Q=.b0449031-35c4-44e8-b9ad-5d5728d86545@github.com>

On Mon, 23 Sep 2024 01:59:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete commented out code
>
> test/hotspot/gtest/runtime/test_os.cpp line 434:
> 
>> 432: #if defined(_WINDOWS)
>> 433:   EXPECT_TRUE(returnedBuffer == buffer);
>> 434:   EXPECT_TRUE(errno == 0);
> 
> I thought we concluded you cannot guarantee that errno==0 after a successful call?

Agreed and deleted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1791595967

From rkennke at openjdk.org  Tue Oct  8 10:19:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:19:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <hguzL3zLq9Svv4sZA-HwiYsvkSDHf5dPNdOmte1HU8Q=.b0caace6-3855-48eb-b93a-e0c81d257e8a@github.com>

On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169:
> 
>> 167:                                 // contention that may happen when a nearby object is modified.
>> 168:   AccessFlags _access_flags;    // Access flags. The class/interface distinction is stored here.
>> 169:                                 // Some flags created by the JVM, not in the class file itself,
> 
> Suggestion:
> 
>   markWord _prototype_header;   // Used to initialize objects' header with compact headers.
> 
> 
> Maybe some comment why this is an instance member.

@tschatzl I just found your comment here, and I'm not sure what you mean, tbh. The prototype_header is a member of Klass because with compact headers, it encodes that Klass in the prototype header. Note that there is planned follow-up work to remove that field and encode the Klass* on the allocation path. https://bugs.openjdk.org/browse/JDK-8341703
Let me know if you still want me to change anything there, or if I can 'resolve' this request.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791602989

From rkennke at openjdk.org  Tue Oct  8 10:19:20 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:19:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <NM8izXWScsGxiKeCqUapYVOoPaUfzdHwJq1GvAH58cs=.28e5b32c-59e0-4b24-8244-9580296d2e84@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
 <rhloCBhjvBZ4Cs8LLpD_UyHIBR08b8NIjXwIEQlirrs=.8a06186e-a315-4977-961c-b172e077bd9a@github.com>
 <W-1ANH5uIdfAoNRB5Mp1wbdS_aswZz8JhdHNNzz6pMw=.b3e0db43-1df0-4b0f-a6fe-ca77aa23d8f1@github.com>
 <k5oJ0MxPfzSI0V4d8SGr8ApvuM9Xpuy25WiJsJ51Tl8=.62dd2a4c-497d-42bc-a513-0151786b19c5@github.com>
 <NM8izXWScsGxiKeCqUapYVOoPaUfzdHwJq1GvAH58cs=.28e5b32c-59e0-4b24-8244-9580296d2e84@github.com>
Message-ID: <BeD13wCpmDGgJ5pAAuIn6OyQuXGZ-yiscMW2wv821Gk=.86f10fb1-ba4e-4d36-8959-d06b4c7e4b89@github.com>

On Tue, 10 Sep 2024 09:28:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> With compact headers, this value should only be used in C2, and not really as an actual offset. An earlier version of the change had the value in src/hotspot/share/opto/type.hpp instead, and only an assert(!UCOH) in oopDesc::klass_offset_in_bytes(). I think this would be a better solution overall, because it prevents accidental (and wrong) usage of the klass_offset in the runtime. Back then it has been rejected by somebody (don't remember), because it made the C2 diff a little messier, so I kept it like it is now. I would prefer to reinstate it, though.
>
>> (Fwiw, the method is also used during Universe initialization).
> 
> Yes, but only in the -UCOH branch.

We will deal with it in a follow-up. https://bugs.openjdk.org/browse/JDK-8340453

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791605009

From ayang at openjdk.org  Tue Oct  8 10:23:20 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 8 Oct 2024 10:23:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
 <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
 <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
 <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
 <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
Message-ID: <PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>

On Tue, 8 Oct 2024 08:12:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I took UCOH into account when this code was written -- the current version of PR would fail the following assert. 
>> 
>> 
>>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>>   assert(CollectedHeap::min_fill_size() >= 2, "inv");
>> 
>> 
>> The least intrusive way, IMO, is to put `if (UCOH) { return; }` right before `// Note: ...`, kind of like what Roman originally put it. I believe the advantage of this style is that when UCOH before always-true, it's obvious this whole method essentially becomes `return`and can be removed right away.
>
> I was thinking that we should remove the entire:
> 
>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>   assert(CollectedHeap::min_fill_size() >= 2, "inv");
> 
> block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.

It's still correct when UCOH is disabled -- therefore, the UCOH check can be placed at the start without changing any existing logic. (The "rest" of this method assumes min-fill-size is 2, `assert(CollectedHeap::min_fill_size() == 2, "inv")`.)

In this PR, since this method doesn't access UCOH, it can be easily forgotten to update this method when the UCOH flag is removed eventually -- it's not obvious to me that `MinObjAlignment >= checked_cast<int>(CollectedHeap::min_fill_size())` is related to (or can be affected by) `UCOH` at first glance.

(I slightly prefer having a `if (UCOH)` inside this method, but considering this method will be nuked in the long run, any short-time decision is fine by me, assuming the failing assert is fixed.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791611304

From rkennke at openjdk.org  Tue Oct  8 10:30:22 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 10:30:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <-UEFgAIQjGBginN0JRoyuwwJLmDssUEQGE_tCP-tRkw=.01ef3f37-01fa-4931-b4f3-571d21252bbd@github.com>
 <jj6GEQDn7YAPHbFlHtE6Hqx4BwCAUh2XEFLTJ1gBmeY=.faa0d50c-9e26-4dec-aeb9-15d3ca11b1b2@github.com>
 <twhuRW8mlXjzlobkiklKNV0IUCWxzM0tu48uX-4rVeQ=.d98ae5da-502c-4f20-8bba-b9ff963dc53b@github.com>
 <z1P1My8MgsUMZ6wFP1Ia0aMFzTkD8oxrGwDI4o4mHrY=.d4c22978-7190-432d-9206-dfbbb1a66a9b@github.com>
 <PnedT3gP8uCpKbCKzXB5s6-KCwWVz1Yx7dHk7r42Tgk=.d4e87b94-058c-49f3-be69-9c4271d04117@github.com>
 <UNtxTRNZWBU2tOkvOOcPnwYUWSPQcniD-O719yjVP58=.8b8b3daf-c71d-4759-9e15-842f21dd7c6d@github.com>
 <PJi9AUPxZGcmcMyXZ01YX8-UkCQWV3CCPlXsR5zoB1w=.23331be1-6069-4241-b628-005309fcfd1b@github.com>
Message-ID: <v9D7WHqlPwZ5D_94YhUU18rk_KY3M3rwAAZ-FK60src=.4404ecb2-6cd1-47a5-b5fb-c79b501aa766@github.com>

On Tue, 8 Oct 2024 10:20:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I was thinking that we should remove the entire:
>> 
>>   // Note: If min-fill-size decreases to 1, this whole method becomes redundant.
>>   assert(CollectedHeap::min_fill_size() >= 2, "inv");
>> 
>> block, since it is now incorrect, guarded by the proper check, and the comment is misleading since we now can have a min-fill-size that is 1.
>
> It's still correct when UCOH is disabled -- therefore, the UCOH check can be placed at the start without changing any existing logic. (The "rest" of this method assumes min-fill-size is 2, `assert(CollectedHeap::min_fill_size() == 2, "inv")`.)
> 
> In this PR, since this method doesn't access UCOH, it can be easily forgotten to update this method when the UCOH flag is removed eventually -- it's not obvious to me that `MinObjAlignment >= checked_cast<int>(CollectedHeap::min_fill_size())` is related to (or can be affected by) `UCOH` at first glance.
> 
> (I slightly prefer having a `if (UCOH)` inside this method, but considering this method will be nuked in the long run, any short-time decision is fine by me, assuming the failing assert is fixed.)

I added an assert(!UCOH) in the implementation so that we don't forget it once the UCOH flag becomes obsolete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1791619505

From rkennke at openjdk.org  Tue Oct  8 11:47:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 11:47:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v38]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix include guards

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/d57dbfc5..4035bb61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=36-37

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

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

From stefank at openjdk.org  Tue Oct  8 12:51:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Oct 2024 12:51:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v38]
In-Reply-To: <XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <XD3mmjy0GRP2dcKyaoxofOIWmOCNn4EqDzmdPBDKgmw=.0392fff7-367d-4553-8f56-62a0885cbfe2@github.com>
Message-ID: <RI9Sw9eEIlbW69JPFcs-TCh8tYLnESkCksxLrSbNZzQ=.b182f3c2-7073-4599-a129-b7198408085f@github.com>

On Tue, 8 Oct 2024 11:47:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix include guards

I have looked through and reviewed most of the files many times and I've tried to give comments in parts of the code where I'm typically not a maintainer.

I'm giving an official Review/Approval of the gc/ code and most of the files in oops/. I'm specifically not approving the compressedKlass* files, because I think that others that are more vested in those bits,  address ranges, and style need to fully Review those changes.

My review comes with a caveat that the there's no significant regressions in GC pauses, marking times, and GC cycle durations, when UCOH is turned off.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2354390888

From mbaesken at openjdk.org  Tue Oct  8 13:44:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Oct 2024 13:44:12 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux with
 toolchain clang
Message-ID: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>

There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

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

Commit messages:
 - JDK-8341722

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

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

From stooke at openjdk.org  Tue Oct  8 14:00:04 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 8 Oct 2024 14:00:04 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v13]
In-Reply-To: <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <DnxU95E6xPzeplFJjqm9uBz9uVtPrabtyBDMHCSY0DA=.96dfd1b4-8464-4c54-8d12-8289260f754e@github.com>
 <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
Message-ID: <4dIhTLTOO25b6WmNJqpPMC4htno0UMMR4s8HtJB-GRA=.1a31e42f-4667-41e1-85a6-e8fd56fabc64@github.com>

On Mon, 23 Sep 2024 02:01:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete commented out code
>
> test/hotspot/gtest/runtime/test_os.cpp line 442:
> 
>> 440:   errno = 0;
>> 441:   returnedBuffer = os::realpath(tmppath, buffer, MAX_PATH);
>> 442:   EXPECT_TRUE(returnedBuffer != nullptr);
> 
> Why the change?

An earlier misundertanding had me thinking the buffer allocated by realpath could be returned.  I've reverted this change.

> test/hotspot/gtest/runtime/test_os.cpp line 452:
> 
>> 450:   EXPECT_TRUE(returnedBuffer == nullptr);
>> 451:   EXPECT_TRUE(errno == ENAMETOOLONG);
>> 452: #endif
> 
> I think it would be better to increase the buffer size on macOS so this remains a positive test for all platforms.

We already have different behaviour flagged for Windows.  If we were to increase the buffer size, it's probably better to simply delete this test as it would behave the same as the test immediately prior.

> test/hotspot/gtest/runtime/test_os.cpp line 460:
> 
>> 458: 
>> 459:   /* the following tests cause an assert in fastdebug mode */
>> 460:   DEBUG_ONLY(if (false)) {
> 
> Suggestion:
> 
>  #ifndef ASSERT
> 
> no need for a runtime check.

fixed.

> test/hotspot/gtest/runtime/test_os.cpp line 467:
> 
>> 465: 
>> 466:     errno = 0;
>> 467:     returnedBuffer = os::realpath(tmppath, buffer, sizeof(buffer));
> 
> This is still not an EINVAL case - the buffer should be null.
> Suggestion:
> 
>     returnedBuffer = os::realpath(tmppath, nullptr, sizeof(buffer));

Somehow my fix for this didn't make it into the last commit.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1791924994
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1791932505
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1791930993
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1791927384

From rcastanedalo at openjdk.org  Tue Oct  8 15:47:16 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 8 Oct 2024 15:47:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
Message-ID: <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>

On Tue, 8 Oct 2024 07:16:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> @rkennke Thanks for the explanation. I attach here a fix which is an extension of existing way of copying while taking care of the smaller object header. Also there are two instances of this in the intrinsic so I have factored the new code into a method and call it from both the places. 
>> [indexof_fix.patch](https://github.com/user-attachments/files/17285239/indexof_fix.patch)
>
> Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.

@rkennke @sviswa7 These changes trigger the following assertion failure:


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
#  guarantee(sect->end() <= tend) failed: sanity


when running the following tests with compact object headers disabled (i.e. default JVM settings):

- `java/lang/StringBuffer/ECoreIndexOf.java`
- `java/lang/String/IndexOf.java`

on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:

CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c


If you need more details to reproduce the issue, please let me know and I will try to help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792121119

From rcastanedalo at openjdk.org  Tue Oct  8 16:01:23 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 8 Oct 2024 16:01:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
Message-ID: <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>

On Tue, 8 Oct 2024 15:44:45 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thank you, @sviswa7! Yes this fix looks correct. I've intergrated it into this PR and re-enabled the indexOf intrinsic for compact headers.
>
> @rkennke @sviswa7 These changes trigger the following assertion failure:
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
> #  guarantee(sect->end() <= tend) failed: sanity
> 
> 
> when running the following tests with compact object headers disabled (i.e. default JVM settings):
> 
> - `java/lang/StringBuffer/ECoreIndexOf.java`
> - `java/lang/String/IndexOf.java`
> 
> on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:
> 
> CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c
> 
> 
> If you need more details to reproduce the issue, please let me know and I will try to help.

Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:

`make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`

In this case I get:


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
#  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0


A few more details of my processor:

family 6 model 158 stepping 13
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792141874

From rkennke at openjdk.org  Tue Oct  8 16:30:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 16:30:47 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v39]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Increase compiler code stubs size for indexOf intrinsic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/4035bb61..b289ef88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=38
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=37-38

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

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

From cjplummer at openjdk.org  Tue Oct  8 16:32:59 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Oct 2024 16:32:59 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:

> 391: 
> 392:       hcreate_r(htab_sz, symtab->hash_table);
> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");

The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1792185871

From rkennke at openjdk.org  Tue Oct  8 16:34:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 8 Oct 2024 16:34:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
Message-ID: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>

On Tue, 8 Oct 2024 15:58:33 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> @rkennke @sviswa7 These changes trigger the following assertion failure:
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (codeBuffer.cpp:1004), pid=96032, tid=29699
>> #  guarantee(sect->end() <= tend) failed: sanity
>> 
>> 
>> when running the following tests with compact object headers disabled (i.e. default JVM settings):
>> 
>> - `java/lang/StringBuffer/ECoreIndexOf.java`
>> - `java/lang/String/IndexOf.java`
>> 
>> on our test macosx-x64 machines. These machines are equipped with Intel Core i7-8700B processors with the following characteristics:
>> 
>> CPU: total 12 (initial active 12) (6 cores per cpu, 2 threads per core) family 6 model 158 stepping 10 microcode 0xf4, cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt, rdtscp, f16c
>> 
>> 
>> If you need more details to reproduce the issue, please let me know and I will try to help.
>
> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
> 
> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
> 
> In this case I get:
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
> #  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
> 
> 
> A few more details of my processor:
> 
> family 6 model 158 stepping 13
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities

Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792186244

From cjplummer at openjdk.org  Tue Oct  8 16:37:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Oct 2024 16:37:09 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent [v2]
In-Reply-To: <VRrXNAupKWfRz6R603yHDedooupj2bjkLDXt68m9DhQ=.88dfc7bc-2555-490e-b214-87015286fe47@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
 <VRrXNAupKWfRz6R603yHDedooupj2bjkLDXt68m9DhQ=.88dfc7bc-2555-490e-b214-87015286fe47@github.com>
Message-ID: <FoZU7T7QJD9MhYKY5xt6r9F3dIo1tc_ES1MIJ15evBQ=.77dd7e42-a784-4e1e-9164-c07028d14ff7@github.com>

On Tue, 8 Oct 2024 06:58:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Remove the support for on-demand debugging via the onjcmd option.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use port 0 in TestAgentEvent

Changes look good. Thanks for taking care of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21387#pullrequestreview-2355012768

From sviswanathan at openjdk.org  Tue Oct  8 16:38:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 8 Oct 2024 16:38:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
 <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
Message-ID: <rDH4CrN_DbFWc6fYt6hudqSKv7CG_lcQCt7CB-wsljk=.313b0c44-e0af-47ca-a41e-76d1a18e2cdc@github.com>

On Tue, 8 Oct 2024 16:30:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
>> 
>> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
>> 
>> In this case I get:
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
>> #  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
>> 
>> 
>> A few more details of my processor:
>> 
>> family 6 model 158 stepping 13
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
>
> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247

Yes, the fix looks correct. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792191386

From wkemper at openjdk.org  Tue Oct  8 17:20:31 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Oct 2024 17:20:31 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
Message-ID: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>

> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:

 - Fix merge error
 - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
 - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
 - Merge branch 'shenandoah/master' into great-genshen-pr-redux
 - Merge
 - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
   
   Reviewed-by: kdnilsen
 - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
   
   Reviewed-by: kdnilsen, ysr
 - Merge
 - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
   
   Reviewed-by: kdnilsen
 - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
   
   Reviewed-by: kdnilsen, shade, ysr
 - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

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

Changes: https://git.openjdk.org/jdk/pull/21273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=02
  Stats: 22593 lines in 229 files changed: 20952 ins; 810 del; 831 mod
  Patch: https://git.openjdk.org/jdk/pull/21273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273

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

From dcubed at openjdk.org  Tue Oct  8 18:40:01 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 8 Oct 2024 18:40:01 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <oYAgmExlC9HBh_gFZwAUVG9wGv53BubUYQJfkMEvXKk=.4a4ecd19-a3dd-4e15-b751-d1838de69e3a@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
 <oYAgmExlC9HBh_gFZwAUVG9wGv53BubUYQJfkMEvXKk=.4a4ecd19-a3dd-4e15-b751-d1838de69e3a@github.com>
Message-ID: <G2qV0juNxe-EAvhGpgw-v79X0Qa30QqK1F6xm-4Ti6Q=.f98b38a6-db1f-4307-a351-c2705a9fe3a6@github.com>

On Mon, 7 Oct 2024 19:50:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have EventGeneratorLoop end after a more predictable duration
>
> Don't worry I'll close 8341518  as a duplicate.

@kevinjwalls - Have you run this fix thru Tier5 in the Oracle CI? That's where we
see a consistent single failure per Tier5 job set.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2400560564

From dcubed at openjdk.org  Tue Oct  8 23:48:28 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 8 Oct 2024 23:48:28 GMT
Subject: RFR: 8341803: ProblemList containers/docker/TestJcmdWithSideCar.java
 on linux-x64
Message-ID: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>

A couple of trivial fixes to ProblemList some noisy tests:
[JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64
[JDK-8341805](https://bugs.openjdk.org/browse/JDK-8341805) ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode

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

Commit messages:
 - 8341805: ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode
 - 8341803: ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64

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

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

From psandoz at openjdk.org  Tue Oct  8 23:56:57 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 8 Oct 2024 23:56:57 GMT
Subject: RFR: 8341803: ProblemList
 containers/docker/TestJcmdWithSideCar.java on linux-x64
In-Reply-To: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>
References: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>
Message-ID: <lYOfpfbp-NAqMvAlle7-C3vjzCZoRlaqj1z8CLbmZW4=.a87bff96-ee36-4213-b023-19e4225769af@github.com>

On Tue, 8 Oct 2024 23:14:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial fixes to ProblemList some noisy tests:
> [JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64
> [JDK-8341805](https://bugs.openjdk.org/browse/JDK-8341805) ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21417#pullrequestreview-2355721589

From dcubed at openjdk.org  Wed Oct  9 00:03:00 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 9 Oct 2024 00:03:00 GMT
Subject: RFR: 8341803: ProblemList
 containers/docker/TestJcmdWithSideCar.java on linux-x64
In-Reply-To: <lYOfpfbp-NAqMvAlle7-C3vjzCZoRlaqj1z8CLbmZW4=.a87bff96-ee36-4213-b023-19e4225769af@github.com>
References: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>
 <lYOfpfbp-NAqMvAlle7-C3vjzCZoRlaqj1z8CLbmZW4=.a87bff96-ee36-4213-b023-19e4225769af@github.com>
Message-ID: <TqtQDtogBLKR1o2qGkdD99pC4Q6sjvjK-MxahNIy4DY=.8c36ff60-9151-4453-963f-93dcb218b456@github.com>

On Tue, 8 Oct 2024 23:54:50 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> A couple of trivial fixes to ProblemList some noisy tests:
>> [JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64
>> [JDK-8341805](https://bugs.openjdk.org/browse/JDK-8341805) ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21417#issuecomment-2401010969

From dcubed at openjdk.org  Wed Oct  9 00:03:01 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 9 Oct 2024 00:03:01 GMT
Subject: Integrated: 8341803: ProblemList
 containers/docker/TestJcmdWithSideCar.java on linux-x64
In-Reply-To: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>
References: <QXoyN_3BBv_nT4vAHQkM4imcq06goa2CFG5rjW1Ic6I=.321eb0d9-9d3c-4567-80ae-98dcf6dacda0@github.com>
Message-ID: <l853RAZAIeJ7IkFjVZvCRiPH4KoOGjPO1Xv2sKURXrc=.f7854efe-4091-4cd9-845e-f9b18fa340d8@github.com>

On Tue, 8 Oct 2024 23:14:55 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial fixes to ProblemList some noisy tests:
> [JDK-8341803](https://bugs.openjdk.org/browse/JDK-8341803) ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64
> [JDK-8341805](https://bugs.openjdk.org/browse/JDK-8341805) ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode

This pull request has now been integrated.

Changeset: f276f58f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f276f58fb427a849549a525a200e95e28952edf4
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8341803: ProblemList containers/docker/TestJcmdWithSideCar.java on linux-x64
8341805: ProblemList five mlvm/indy/func/jvmti tests in Xcomp mode

Reviewed-by: psandoz

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

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

From dcubed at openjdk.org  Wed Oct  9 00:06:00 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 9 Oct 2024 00:06:00 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <5jaKmBk24j4mfs22UF7_oaxM7f5ffrEbnAOzzaIjU_4=.2f0a3071-0a74-4a08-8070-15dbea0464a6@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

This test has been ProblemListed via: https://github.com/openjdk/jdk/pull/21417
We reached 24 sightings in the main CI which is way past my limit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2401015745

From duke at openjdk.org  Wed Oct  9 01:15:11 2024
From: duke at openjdk.org (duke)
Date: Wed, 9 Oct 2024 01:15:11 GMT
Subject: RFR: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging [v3]
In-Reply-To: <OpcyS1wvmg0lm_w0HFX5wZPj2r-FtXKNuySFu--PbPQ=.cc126ac2-d302-465a-8b5c-f1188ca35722@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
 <OpcyS1wvmg0lm_w0HFX5wZPj2r-FtXKNuySFu--PbPQ=.cc126ac2-d302-465a-8b5c-f1188ca35722@github.com>
Message-ID: <OUUrT_enYrlf2twVRskbEYcuv71aeVHPXs0uP5JGsT8=.cdee86b2-c1ee-4268-b6cd-5b573b798dc8@github.com>

On Tue, 8 Oct 2024 04:17:31 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
>> 
>> Testing:
>> tier1,tier2,tier3
>> tier6-comp,tier8-comp
>
> Ramkumar Sunderbabu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   commit after resolving conflicts

@rsunderbabu 
Your change (at version 4b3bba2568c601fa9a03908e604573a7e0ba6e7a) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21392#issuecomment-2401078991

From rsunderbabu at openjdk.org  Wed Oct  9 03:15:00 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 9 Oct 2024 03:15:00 GMT
Subject: Integrated: 8341588: Remove CollectionUsageThreshold.java from
 ProblemList-Xcomp for debugging
In-Reply-To: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
References: <WjaHnvvWi0i5wbtK5Bsg52JivYM7gP6X58da-UsM3oI=.e302cf46-d8d9-4a69-87a5-017d63512d6a@github.com>
Message-ID: <hYQL07SiuW4UyFxH1ubOCAU4iC13NFCICZ9_oak2W9Y=.91340cf3-1b48-4986-8788-ffc68dfb1c26@github.com>

On Mon, 7 Oct 2024 15:28:19 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> JDK-8318668 was not reproducible in repeated runs. Hence, I am pulling it out of problem listing. Additionally I have increased logging so that it is easier to debug when the issue happens again.
> 
> Testing:
> tier1,tier2,tier3
> tier6-comp,tier8-comp

This pull request has now been integrated.

Changeset: de90204b
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de90204b60c408ef258a2d2515ad252de4b23536
Stats:     7 lines in 3 files changed: 3 ins; 1 del; 3 mod

8341588: Remove CollectionUsageThreshold.java from ProblemList-Xcomp for debugging

Reviewed-by: lmesnik, kevinw

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

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

From lmao at openjdk.org  Wed Oct  9 03:30:07 2024
From: lmao at openjdk.org (Liang Mao)
Date: Wed, 9 Oct 2024 03:30:07 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
Message-ID: <GWpGtSgoRD5u1L7TwA7URqGqlBPMsdQH1_tYFR6uzCY=.309147f4-194a-47eb-882f-c7bfcfcbaf00@github.com>

On Tue, 8 Oct 2024 17:20:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
> 
>  - Fix merge error
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options?
```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc*  -XX:MetaspaceSize=1g   -jar specjbb2015.jar -m COMPOSITE```

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

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2401194597

From mbaesken at openjdk.org  Wed Oct  9 06:27:59 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 06:27:59 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
Message-ID: <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>

On Tue, 8 Oct 2024 16:30:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
> 
>> 391: 
>> 392:       hcreate_r(htab_sz, symtab->hash_table);
>> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");
> 
> The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.

Hi Chris , I created https://bugs.openjdk.org/browse/JDK-8341820 for the return value checking.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1792911176

From rcastanedalo at openjdk.org  Wed Oct  9 06:30:18 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Oct 2024 06:30:18 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
 <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
Message-ID: <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@github.com>

On Tue, 8 Oct 2024 16:30:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Turns out I can also reproduce the issue on my linux-x64 machine (Intel Core i7-9850H), simply running:
>> 
>> `make run-test TEST="java/lang/String/IndexOf.java" CONF=linux-x64-debug`
>> 
>> In this case I get:
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (codeBuffer.hpp:200), pid=51958, tid=51975
>> #  assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x00007c2778843560 <= 0x00007c27788543b3 <= 0x00007c27788543b0
>> 
>> 
>> A few more details of my processor:
>> 
>> family 6 model 158 stepping 13
>> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp vnmi md_clear flush_l1d arch_capabilities
>
> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247

That seems to work, thanks @rkennke!

Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1792911644

From stooke at openjdk.org  Wed Oct  9 07:16:13 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 9 Oct 2024 07:16:13 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v14]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <XebTX7gfY5pDFskd93yVM26KGG18aKcBl9OaDjUu3lc=.0bb56be1-da4b-40d1-bbb5-dff140db387c@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  feedback from review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/920f67d8..6715569a

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

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

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

From jwaters at openjdk.org  Wed Oct  9 07:28:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 9 Oct 2024 07:28:58 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
Message-ID: <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>

On Wed, 9 Oct 2024 06:25:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 393:
>> 
>>> 391: 
>>> 392:       hcreate_r(htab_sz, symtab->hash_table);
>>> 393:       // guarantee(rslt, "unexpected failure: hcreate_r");
>> 
>> The commented out guarantee line references rslt. I'm not so sure why it was commented out, but it goes back to the initial load of the file 17 years ago. It looks like the correct thing to do if rslt is null is to "goto bad;" but that change is probably beyond the scope of this PR. Maybe file a new CR.
>
> Hi Chris , I created https://bugs.openjdk.org/browse/JDK-8341820 for the return value checking.

Might be a good idea to have rslt commented out rather than removed outright if we don't want to forget about it. guarantee on a variable that doesn't exist will be rather confusing to anyone reading through the code

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793006705

From sspitsyn at openjdk.org  Wed Oct  9 07:41:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 07:41:01 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <l62MaX_wTbJ-eaAjO6fRx2W3DgWyZNY1IusPNj7Nxas=.7f90107c-8597-4c50-b6da-7ff399886812@github.com>

On Mon, 7 Oct 2024 22:41:06 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test id=virtual
> 
> Having 'id=virtual' not needed and might confuse people. They expect to have other test variations for platform.

Good suggestion, thanks. Removed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 32:
> 
>> 30: 
>> 31: public class CheckHiddenFrames {
>> 32:     private static final String AGENT_LIB = "CheckHiddenFrames";
> 
> It is not used?

Thanks, removed. I saw it but forgot to remove.

> test/hotspot/jtreg/serviceability/jvmti/vthread/CheckHiddenFrames/CheckHiddenFrames.java line 43:
> 
>> 41: 
>> 42:     public static void main(String[] args) throws Exception {
>> 43:         Thread thread = Thread.ofVirtual().unstarted(CheckHiddenFrames::test);
> 
> You can use 
> startVirtualThread
> to save one line.

Good suggestion, thanks.
Changed to use startVirtualThread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793023718
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793024733
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793023025

From sspitsyn at openjdk.org  Wed Oct  9 07:57:57 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 07:57:57 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <iHBB9WaX2eRMLqSEU9AljvIf2Uijye3ShZFidwO4A5Q=.5e5f20b7-fac9-4ed8-953c-2ce4e231da17@github.com>

On Mon, 7 Oct 2024 23:43:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2009:
> 
>> 2007:   bool is_virtual = java_lang_VirtualThread::is_instance(thread_oop);
>> 2008: 
>> 2009:   // Target can be virtual or platform thread.
> 
> Can you please explain in comment why is it needed to disable all threads for platform target thread.

Thank you for suggestion. Explained comment.
Now, it looks as below:

  // Target can be virtual or platform thread.
  // Disable VTMS transition for one thread if it is virtual.
  // Otherwise, disable VTMS transitions for all threads
  // to protect against VTMS transitions in carrier threads.
  // For the latter VTMS transitions are disabled for all threads by several reasons:
  // - carrier threads can mount virtual threads which may cause incorrect behavior
  // - it is good invariant if we can ensure no VTMS transition might happen at some points 
  // - there is no mechanism to disable transitions for a specific carrier threads yet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793048247

From sspitsyn at openjdk.org  Wed Oct  9 08:01:58 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 08:01:58 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <10mZcVsZJP5Rcb-M1_EJxOeamq1PWSp1LPUZQSGh2Zc=.82fc7d27-0ce7-417c-96ce-446a0356f340@github.com>
Message-ID: <kXRB8fBrS6h55TTpQDt1H0xBGjOgpHze4_6DFOGznjo=.c1a91b7a-f5d5-43d1-aa75-0334e1f57dd7@github.com>

On Tue, 8 Oct 2024 00:11:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:
> 
>> 689: 
>> 690:   if (is_virtual || jt->is_in_VTMS_transition()) { // filter out pure continuations
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 
> Wouldn't be easier to split method `check_and_skip_hidden_frames` to skip_yeilds and skip_transition frames? 
> BTW Also it is unclear shouldn't the `@Hidden` methods be skipped from all jvmti frame streams?

Good suggestion, thanks. I was also thinking about it but was not sure it can be simplified.
JVMTI does not support @Hidden annotation which is used in Java `printStackTrace()` api implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1793054337

From mbaesken at openjdk.org  Wed Oct  9 10:38:57 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 10:38:57 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
 <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
Message-ID: <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>

On Wed, 9 Oct 2024 07:26:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Might be a good idea to have rslt commented out 

Why not; Chris what do you say ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793282296

From jsjolen at openjdk.org  Wed Oct  9 10:58:59 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 9 Oct 2024 10:58:59 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
Message-ID: <-RsM5drgIB3p9AOkmUVuDkzPAmyujn6I91NBZiv7Eb8=.ca6112f4-fa6a-490c-b594-cb37f97aa129@github.com>

On Wed, 2 Oct 2024 13:28:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - 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>

Hi,

Big thanks to David for taking the heavy brunt of reviewing this change. This code looks good to me, it's a bit unfortunate that we have to export `MemTracker::reduce_tracking_to_summary` for the limited use case of exiting the VM on error, but OK. Let's wait for Thomas to come back for this change, I think it's not more than fair that he gets to have another look at this.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20852#pullrequestreview-2356793662

From kevinw at openjdk.org  Wed Oct  9 11:14:01 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Oct 2024 11:14:01 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <kUskwXpBnupwG2IAu3mFOoZAMBtlth3WeeYgxx7OA-8=.cc013682-ee67-4254-84ce-d1e0127c53a7@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

Hmm, actually no I _can_ still get a failure.

This change is still worthwhile, but not a reason to un-problemlist the test just yet (so thanks, yes problemlisting was a good step).

Previously, the EventGeneratorLoop had shown its ending message, so it was not surprising the test failed.

Now I don't see that message (good, EventGeneratorLoop still running), but can still get the same kind of failure
(java.lang.RuntimeException: 'sun.tools.jcmd.JCmd' missing from stdout/stderr).  More to do in 8341518...

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2402025140

From aboldtch at openjdk.org  Wed Oct  9 11:21:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 11:21:27 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with deflation
Message-ID: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>

This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).

When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).

I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.

For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 

However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.

Object o = new Object();
synchronized(o) {
  o.wait(1);
}
synchronized(o) {
  deoptimize();
}

got transformed to 

Object o = new Object();
synchronized(o) {
  o.wait(1);
}
// synchronized(o) { Eliminated lock
  deoptimize();
// }


As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

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

Commit messages:
 - Decouple from EA and potential partial lock elimination
 - 8341819: LightweightSynchronizer::enter_for races with deflation

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

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

From mbaesken at openjdk.org  Wed Oct  9 11:44:35 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 11:44:35 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust gcc warning settings; bring back rslt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21407/files
  - new: https://git.openjdk.org/jdk/pull/21407/files/ee3546b1..705bd07b

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

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

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

From mbaesken at openjdk.org  Wed Oct  9 11:47:00 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Oct 2024 11:47:00 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <-lxjK9aLbWpegpHr8XKWFqLck4OShpBuuBpWrLMkMyk=.5450dde8-025f-4a94-8f50-605f246e3578@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

I brought back `rslt`  but uncommented, as suggested.

Additionally I removed some special gcc warning setting; those disabled the symtab.c and LinuxDebuggerLocal.cpp  related warnings when compiling with gcc (brings clang and gcc behavior a bit closer together).

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

PR Comment: https://git.openjdk.org/jdk/pull/21407#issuecomment-2402092775

From rkennke at openjdk.org  Wed Oct  9 11:49:05 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 9 Oct 2024 11:49:05 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation
In-Reply-To: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
Message-ID: <OS5lN_VOeONH_Vci9VFTob5f-1t2NqFhAb0uITxODRQ=.b86d139f-b42d-401e-b70c-e0c35896579d@github.com>

On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
> 
> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
> 
> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> synchronized(o) {
>   deoptimize();
> }
> 
> got transformed to 
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> // synchronized(o) { Eliminated lock
>   deoptimize();
> // }
> 
> 
> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

Looks good to me. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21420#pullrequestreview-2356904757

From aboldtch at openjdk.org  Wed Oct  9 11:50:17 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 11:50:17 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational Mode
Message-ID: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>

This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

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

Commit messages:
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - Add missing problem-listing
 - Remove x from jdk.hotspot.agent
 - 8341692: Implement JEP 490: ZGC: Remove the Non-Generational Mode

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341692
  Stats: 39423 lines in 406 files changed: 152 ins; 39003 del; 268 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

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

From stooke at openjdk.org  Wed Oct  9 12:12:36 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 9 Oct 2024 12:12:36 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v15]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <Tqg3sleE3fF6Y0UBNx3kJjvj4tUEKADFEQlxYn96iHg=.47b9aa75-ee50-49ed-95c1-9e46da99c639@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  account for Windows behviour changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/6715569a..e1b2c534

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=13-14

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

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

From aboldtch at openjdk.org  Wed Oct  9 12:57:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 9 Oct 2024 12:57:36 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:

 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21401/files
  - new: https://git.openjdk.org/jdk/pull/21401/files/e5865bc8..22c243a6

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

  Stats: 53 lines in 8 files changed: 21 ins; 23 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

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

From ihse at openjdk.org  Wed Oct  9 13:25:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Oct 2024 13:25:48 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <ZNzx_44LSlFCNk8TdkJ50MT6nE4-OEyrOeK4sBvjPik=.14a10996-5b1d-4c59-8f8a-4c494153ca44@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Build changes look good.

Are you on a direct track towards winning over the title of Dr Deprecator? ;-)

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357082736

From stefank at openjdk.org  Wed Oct  9 13:25:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 9 Oct 2024 13:25:49 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <QxLgeCEPB2-nU4a4iX8D6-SCg-RZCJdzWa_IJJlcaAg=.88feee12-f9a0-484f-98b2-2d60b8709d5b@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

src/hotspot/share/runtime/arguments.cpp line 523:

> 521: 
> 522:   { "MetaspaceReclaimPolicy",       JDK_Version::undefined(), JDK_Version::jdk(21), JDK_Version::undefined() },
> 523:   { "ZGenerational",                JDK_Version::jdk(23), JDK_Version::jdk(24), JDK_Version::undefined() },

FTR: This line depends on what version the JEP gets targeted to.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21401#discussion_r1793510168

From stefank at openjdk.org  Wed Oct  9 13:27:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 9 Oct 2024 13:27:13 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <H2vRaCgFEUjFZxYtRvjgLuGLm1W1VpYOCpOafn2qGHg=.a8e84a0f-b072-4212-a5e2-f659792e1945@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Looks good to me!

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

PR Comment: https://git.openjdk.org/jdk/pull/21401#issuecomment-2402271738

From pchilanomate at openjdk.org  Wed Oct  9 14:15:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 9 Oct 2024 14:15:59 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation
In-Reply-To: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
Message-ID: <qz37-Klh77UhKFye7bvzXvTj5PtNBjWKQ5rSY9X1kp0=.72c971a3-e1d3-4245-be9a-f4577278950d@github.com>

On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
> 
> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
> 
> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> synchronized(o) {
>   deoptimize();
> }
> 
> got transformed to 
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> // synchronized(o) { Eliminated lock
>   deoptimize();
> // }
> 
> 
> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

Looks good to me, thanks.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21420#pullrequestreview-2357290865

From eosterlund at openjdk.org  Wed Oct  9 14:46:00 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 9 Oct 2024 14:46:00 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <YoFjg-VDCRuEpslSIZE7glzDpNJJWCxlA_c2DaIVgkk=.33c2f427-192d-4b85-8bff-4ed8ac666af4@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357380323

From rsunderbabu at openjdk.org  Wed Oct  9 15:06:11 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 9 Oct 2024 15:06:11 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support
Message-ID: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>

The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".

Positive Testing:
tier1,tier2,tier3 - to check stability
tier5 - to run container tests

Negative Testing:
Ran the following groups in hosts where container is not present.
open/test/hotspot/jtreg/containers/
open/test/jdk/jdk/internal/platform/docker/
open/test/jdk/jdk/internal/platform/cgroup/

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

Commit messages:
 - corrected the copyright headers
 - initial commit

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

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

From cjplummer at openjdk.org  Wed Oct  9 15:38:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Oct 2024 15:38:03 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <9xtyq-yoawgL56BKui49A19DYpPHJZVC4Cw5a_gQLuY=.75aa9044-3b40-49fc-bb80-5ad5e4865fe3@github.com>
 <5UMeyoUDYQdXMI4WrOL9wvprNM3T7aJcFmGy5XQNQqo=.e4b257cf-d52a-4b5f-99e5-7bb5d5deb325@github.com>
 <0phEjRhdkzoktdn5f-VmwNddCFABbKUw0XKgLENxsII=.44778b32-2039-4b52-9b97-40b5ee690675@github.com>
 <hTF-irWGYZkkbPeiwSvWNBp6N_UiGJdWRlwJ5UXBoQA=.a6ab4ebc-26d2-4c39-924e-00643f031756@github.com>
Message-ID: <z5f8EoUCOIWMfKH-bnR1qGPOcSMI8uCpNDPU84r9guI=.f50660b7-063a-432e-b88e-d4d16c5c4b61@github.com>

On Wed, 9 Oct 2024 10:36:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Might be a good idea to have rslt commented out rather than removed outright if we don't want to forget about it. guarantee on a variable that doesn't exist will be rather confusing to anyone reading through the code
>
>> Might be a good idea to have rslt commented out 
> 
> Why not; Chris what do you say ?

Yeah, I think it is good like this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1793746144

From cjplummer at openjdk.org  Wed Oct  9 15:38:01 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Oct 2024 15:38:01 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <kWpzDLtOVJSNNs118tseqdQYE7FdENDFocw0gTXU84s=.a452b2f5-97ca-4d61-aacc-438cb747a719@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21407#pullrequestreview-2357520081

From sviswanathan at openjdk.org  Wed Oct  9 16:25:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 16:25:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
 <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
 <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
 github.com>
Message-ID: <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>

On Wed, 9 Oct 2024 06:25:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Oh! We need to increase the compiler stub size for the indexOf changes. Strange that it blows up like this, I was sure there was a better check for this somewhere. I changed it like this, let me know if you agree that this is the correct fix:
>> https://github.com/openjdk/jdk/pull/20677/commits/b289ef885816958d9806c76f473b10e34a39e247
>
> That seems to work, thanks @rkennke!
> 
> Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?

Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1793814453

From kevinw at openjdk.org  Wed Oct  9 17:31:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Oct 2024 17:31:06 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters
In-Reply-To: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
Message-ID: <WJ9RgnrIr-h6kBt3MMa7cGsX5_LnTKjceablhv7347Q=.7f44541c-8058-4808-8bca-3472fcec0ecf@github.com>

On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".

Hi,
Looking for input.  We do _need_ this change, or something like it, as we have the FILE type out there in the product, and JMC does not understand it (nor would any other app).

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

PR Comment: https://git.openjdk.org/jdk/pull/21040#issuecomment-2402897334

From rcastanedalo at openjdk.org  Wed Oct  9 17:44:24 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 9 Oct 2024 17:44:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
 <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
 <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
 github.com>
 <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
Message-ID: <ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>

On Wed, 9 Oct 2024 16:21:53 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> That seems to work, thanks @rkennke!
>> 
>> Since the [indexOf changes](https://github.com/openjdk/jdk/pull/20677/files#diff-ae1139bb5342494f9761e04389b090c543391bfdd7817af1625e854357c96e63) are complex and affect the default JVM configuration, they should be subject to the same level of scrutiny as if they were a standalone RFE, i.e. approved by at least a second reviewer. @sviswa7 could someone else at Intel have a second look and explicitly approve them?
>
> Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.

Yes, that would be great. In the meantime, I ran a few thousand times the randomized test `java/lang/StringBuffer/ECoreIndexOf.java` with and without compact object headers, on product and debug builds, on different x64 implementations, and found no failures.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1793917912

From prr at openjdk.org  Wed Oct  9 18:27:02 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 9 Oct 2024 18:27:02 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v2]
In-Reply-To: <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <7ekcZqBSpXnzKa2EHQKPNZhhrBIrL7A0ubEBpWXMVUc=.88bfa7d4-c75a-4b56-9c2c-da8acc6f605a@github.com>
Message-ID: <pOGPEw3oV9Qyt57fCI4B9Fj-3RAtUCKWvgZPf_c3uog=.1bcf7dfc-7792-428c-b2eb-64ff52db2c7f@github.com>

On Wed, 9 Oct 2024 12:57:36 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments

the 2D/AWT test changes are fine. I've not looked at anything else.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2357882378

From duke at openjdk.org  Wed Oct  9 19:13:02 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Wed, 9 Oct 2024 19:13:02 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <kUskwXpBnupwG2IAu3mFOoZAMBtlth3WeeYgxx7OA-8=.cc013682-ee67-4254-84ce-d1e0127c53a7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
 <kUskwXpBnupwG2IAu3mFOoZAMBtlth3WeeYgxx7OA-8=.cc013682-ee67-4254-84ce-d1e0127c53a7@github.com>
Message-ID: <j-dreCD7dqLIn5V2bihQz5aqY5b5OJbA_7yVozQqvwc=.153abbad-1c69-43e9-998b-3f2ae82235b5@github.com>

On Wed, 9 Oct 2024 11:11:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have EventGeneratorLoop end after a more predictable duration
>
> Hmm, actually no I _can_ still get a failure.
> 
> This change is still worthwhile, but not a reason to un-problemlist the test just yet (so thanks, yes problemlisting was a good step).
> 
> Previously, the EventGeneratorLoop had shown its ending message, so it was not surprising the test failed.
> 
> Now I don't see that message (good, EventGeneratorLoop still running), but can still get the same kind of failure
> (java.lang.RuntimeException: 'sun.tools.jcmd.JCmd' missing from stdout/stderr).  More to do in 8341518...

I take it you have not been able to reproduce the problem outside CI yet @kevinjwalls?

Have you been able to pinpoint anything about where or when the failures happen? OS version, kernel version, Docker version, anything else? I saw some notes about it in https://bugs.openjdk.org/browse/JDK-8341518, is OEL referring to Oracle Linux? Only ever failures on OEL 7, never on OEL 8?

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2403097164

From sgehwolf at openjdk.org  Wed Oct  9 19:38:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Oct 2024 19:38:11 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <Q8b9Qi1JYyykIoZS8IhWDyGjQ_K_7LwIQk2b_LWNMuc=.b55d86e6-d9e7-4457-bd5a-9df6eaf554ad@github.com>

On Wed, 9 Oct 2024 14:50:30 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

Seems OK to me. One minor nit.

test/lib/jdk/test/lib/Container.java line 27:

> 25: 
> 26: public class Container {
> 27:     // Use this property to specify container location on your system.

Suggestion:

    // Use this property to specify container runtime location (e.g. docker) on your system.

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

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2358152114
PR Review Comment: https://git.openjdk.org/jdk/pull/21423#discussion_r1794127601

From kevinw at openjdk.org  Wed Oct  9 19:48:12 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Oct 2024 19:48:12 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <aOIDFcy6N_Ims-89p1mOMQMH2qLWtkX_DgJex-a0Ov0=.e4110110-039c-43bd-82f6-7ec445a502da@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

Yes OEL was Oracle Linux:

Our CI tests with docker run on Oracle Linux 7, and they fail with elevated-true (i.e. with "--cap-add=NET_BIND_SERVICE").

Our CI runs with Oracle Linux 8 use podman and they are OK using "--cap-add=NET_BIND_SERVICE"

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2403302429

From sviswanathan at openjdk.org  Wed Oct  9 20:28:29 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 9 Oct 2024 20:28:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v26]
In-Reply-To: <ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <fEpfi4CzTFr1Pl-IyOAVyHNXWlVz33lHKQyzVY0kBc8=.cc39355b-ee7a-4118-952a-28e4184eec84@github.com>
 <DKuidQyyiiJOsrerLCeziselVyG9Ztpzsyc64ZNjlI4=.722fc4f7-d7cc-49df-9d82-5c1094508f74@github.com>
 <hdttC4LhHE6y6Nbq0jjJwxxF4W0hTfJLK_siODDCBkM=.1667f495-fcd9-4b7f-8d58-24e27665eeb3@github.com>
 <fWSdSqQfhOrGpFoExiaO4L-UDtR90_t0gRxp9YBO3_c=.0173618e-f392-4921-8fae-39d44b24de08@github.com>
 <6PTWMepIDuZDdPfN3xNKV1vqUyO_R4yCSeiSTpYIyyQ=.61a5b462-7114-4385-a6d7-40e5c7b0005d@github.com>
 <C5LwWrsa-VO87kdm_sYuisTGMsHoxv4Eoe0QikdkusE=.63b0993c-86c8-4ef6-a3cf-bc8a67e10815@github.com>
 <WOlTJMNHCr_Kk69sEIUwCVI3ZbiRlckY4TSBRfL7zoA=.1a4c59f1-a000-4d9f-abbc-36b24ed5105e@github.com>
 <UjwpWz9Y3W8WRzYHZmDk9EvoiLSCZG1aai5oASGtDKA=.68cab6dd-e67d-4651-a9c9-75dccf42d85f@github.com>
 <l_7f8gGpIdG9H3Ini5vHWruIa0oDi7fkn2Lz5thDI5c=.969b804f-bae2-48e1-9c44-e631d90037e7@github.com>
 <BtvwMUG5tcy_zU4tRG3Q5VVw08qE_3gSE35
 wCxlDnj4=.954353e5-cab2-48f4-b0f2-5852e586ba20@github.com>
 <zi8MM6qUWhvxPSyb3ewa3baXWhmDIDlut2uYUQmWvcw=.7b32fa42-7a3f-43bb-8f15-fe6b8e66c49b@github.com>
 <TSxYcKKfAdx7SsVcq6iwiySCLlkoVbXQO7a25vsiG4k=.29e59a6c-b8e0-42e9-8bdd-cc8ca23df146@github.com>
 <YpG7vj6W3LnbhvvRhaeLmLeBzc_vlzlzmD74xVu1FQY=.14a57f09-74c1-4b2f-962c-c923961c067c@github.com>
 <YrOurf-ql2uciTYRjGDnvVIb3r9K1pYphx2yRism6SQ=.f5b2510c-d384-4e78-906b-08267a218185@github.com>
 <YqRmzdVypPfgEUFG9TqiQvD846aTd9SE9pU746Ed3HU=.a0349ab7-aabc-471c-9375-ef432a187caa@github.com>
 <6yrLSIp1cwJXxYVoMfSLxhbFA9Qdc9P3ML25QW0sfL4=.aa8bedac-1faa-4148-bcfc-a1434ddc9bac@github.com>
 <lD7f-h93ZqWOHoJtIECJfizoH74j3_iwG2VG_jAYR1o=.db4be907-c20a-4f96-9b9e-e34eefa2e7f3@github.com>
 <Z0hfAlQlvNDCIcDK3LTPO4yKYN_dJnVa7CVinbFPgLI=.d1f5d4e7-8ff1-417c-8e8f-c2666a64f569@github.com>
 <hIf7108CCy2cYFW9shrUuP_oR7GcrDN5czlDK7Erbt0=.49632b4b-d1f2-40a9-80da-47e89f46b479@github.com>
 <ouoemlEpzqpgckNviJxccPlr69RhOeCy2KCxMhRX8rg=.203da6e1-fa45-4377-bebe-2c41eb8e344d@
 github.com>
 <Xl2cSg6Ql6ttcW4mtRAi7uq-lKjPX37xNqMF1zG398w=.90ceecb4-e531-417c-ae96-b03dba0fe313@github.com>
 <ffUwCDUB5JmTDFXVZsEKkLiNfkF2D3YTSRp9qX13orc=.f4e454c3-9bf6-46ad-9491-89a50a8e7810@github.com>
Message-ID: <mcGN2Xuld1ZujJVmIkv3NBCPbspQ7YdjXtnb_0ypftk=.75e66e61-97d0-4ae8-bc98-b6af592a1853@github.com>

On Wed, 9 Oct 2024 17:41:37 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Yes, @vpaprotsk could review the changes that we made in src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp.
>
> Yes, that would be great. In the meantime, I ran a few thousand times the randomized test `java/lang/StringBuffer/ECoreIndexOf.java` with and without compact object headers, on product and debug builds, on different x64 implementations, and found no failures.

Thanks a lot @robcasloz for doing the testing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1794181528

From cjplummer at openjdk.org  Wed Oct  9 20:39:12 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Oct 2024 20:39:12 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters
In-Reply-To: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
Message-ID: <lHdE8v-GZCMG3Ki9NIziZuZQpobrG39oMMKvM9eOdFM=.e02b01cf-36cb-4913-97ee-6d7ffebf547d@github.com>

On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".

test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java line 133:

> 131: 
> 132:     // Knowledge of the types made public by com.sun.management.internal.DiagnosticCommandImpl
> 133:     private static final String [] publicTypes = new String [] { "INT", "STRING", "BOOLEAN", "STRING SET", "MEMORY SIZE", "NANOTIME" };

These type are "implementation dependent", yet we are referring to them as public types. Also, these "public types" are now in two different places. If they were public, only one copy should be needed. Maybe we just need better terminology since they are not actually public, but just happen to be the types the implementation is know to return...err, I guess you could say the leak out to the "public". Sigh. IDK. I guess I just feel we could do a better job in how we refer to these types in the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21040#discussion_r1794193671

From sspitsyn at openjdk.org  Wed Oct  9 22:47:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 22:47:31 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v2]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <qkkPxqZteiOkzUaZyknfx0hDPbHXLfWZFjTKJHIiTBU=.bea75699-5740-4622-b02a-521be2fbe527@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

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

  review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/8615d2b9..8ec7bd3f

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

  Stats: 42 lines in 3 files changed: 23 ins; 12 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

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

From sspitsyn at openjdk.org  Wed Oct  9 22:58:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Oct 2024 22:58:33 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

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

  Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/8ec7bd3f..3317ea81

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

  Stats: 14 lines in 2 files changed: 8 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

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

From stooke at openjdk.org  Thu Oct 10 06:44:29 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 10 Oct 2024 06:44:29 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v16]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <f2kLm1lnJ1-TVEZ7luklJ4cVs1sQNqWvVJIYj39wLNA=.d0bf5cf8-03bd-4b13-bce8-bdfa17803e28@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  remove accidently commited file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/e1b2c534..e8c29ff5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=14-15

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

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

From lucy at openjdk.org  Thu Oct 10 06:46:13 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 10 Oct 2024 06:46:13 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <8FNj6NUjFGDmgaThzmacRV9g584Pm6_5v-wdtjJCao8=.877913eb-0cfd-4b4e-971a-d39525cf77e9@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21407#pullrequestreview-2359153153

From stooke at openjdk.org  Thu Oct 10 06:51:13 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 10 Oct 2024 06:51:13 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v17]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <CwVz2eJEQ-zn4vVD5GyZyyimU65ZhWuQA53uYo5pds0=.1cdbc9dc-ec1b-4c46-a80f-45cbeebacc04@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

 - Merge branch 'master' into pr_windows_realpath
 - remove accidently commited file
 - account for Windows behviour changes
 - feedback from review
 - delete commented out code
 - fix realpath test on macOS
 - remove tabs
 - remove conditional compilation
 - Merge branch 'master' into pr_windows_realpath
 - fix realpath() test for POSIX
 - ... and 12 more: https://git.openjdk.org/jdk/compare/281b387e...9fe1466b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/e8c29ff5..9fe1466b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=15-16

  Stats: 67910 lines in 1125 files changed: 55391 ins; 6843 del; 5676 mod
  Patch: https://git.openjdk.org/jdk/pull/20683.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20683/head:pull/20683

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

From mbaesken at openjdk.org  Thu Oct 10 07:24:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 07:24:15 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <Z3NDDQE7tjdPILWu5DWvD9grFYyzyZwbibRPtDgCEaA=.4098e049-b95a-4b89-a02a-dcec1e7e7b6e@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

Thanks for the reviews and suggestions !

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

PR Comment: https://git.openjdk.org/jdk/pull/21407#issuecomment-2404260346

From mbaesken at openjdk.org  Thu Oct 10 07:24:16 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 07:24:16 GMT
Subject: Integrated: 8341722: Fix some warnings as errors when building on
 Linux with toolchain clang
In-Reply-To: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
Message-ID: <Z7A56gGI5IwoycWemvUUcTAbiLFB6Tp5C_bfkTHWFgg=.dcce4122-c3cf-44be-9421-8887eaf09aca@github.com>

On Tue, 8 Oct 2024 13:38:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .

This pull request has now been integrated.

Changeset: e7c5bf45
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7c5bf45f753ad6459c666a4dd4a31197b69e05e
Stats:     12 lines in 5 files changed: 1 ins; 8 del; 3 mod

8341722: Fix some warnings as errors when building on Linux with toolchain clang

Reviewed-by: cjplummer, lucy

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

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

From kevinw at openjdk.org  Thu Oct 10 08:12:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Oct 2024 08:12:11 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters
In-Reply-To: <lHdE8v-GZCMG3Ki9NIziZuZQpobrG39oMMKvM9eOdFM=.e02b01cf-36cb-4913-97ee-6d7ffebf547d@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
 <lHdE8v-GZCMG3Ki9NIziZuZQpobrG39oMMKvM9eOdFM=.e02b01cf-36cb-4913-97ee-6d7ffebf547d@github.com>
Message-ID: <K1R9BgPnv_EVGwribF8YZV_tf7cc3UcZ4QbS1ElG9hI=.f59a5502-9115-4646-a09d-5e9aee1546fb@github.com>

On Wed, 9 Oct 2024 20:36:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".
>
> test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java line 133:
> 
>> 131: 
>> 132:     // Knowledge of the types made public by com.sun.management.internal.DiagnosticCommandImpl
>> 133:     private static final String [] publicTypes = new String [] { "INT", "STRING", "BOOLEAN", "STRING SET", "MEMORY SIZE", "NANOTIME" };
> 
> These type are "implementation dependent", yet we are referring to them as public types. Also, these "public types" are now in two different places. If they were public, only one copy should be needed. Maybe we just need better terminology since they are not actually public, but just happen to be the types the implementation is know to return...err, I guess you could say the leak out to the "public". Sigh. IDK. I guess I just feel we could do a better job in how we refer to these types in the code.

Right, public as in the type names which are observable by applications/users, not as in Java type terminology.

Comment could be:

// Knowledge of the implementation-dependent types in DiagnosticCommandImpl, seen by applications/users
// (see the DiagnosticCommandMBean Descriptor, field "dcmd.arg.type").

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21040#discussion_r1794931004

From kevinw at openjdk.org  Thu Oct 10 08:51:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 10 Oct 2024 08:51:38 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v2]
In-Reply-To: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
Message-ID: <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>

> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".

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

 - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
 - Update comment about type name knowledge
 - Test update
 - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21040/files
  - new: https://git.openjdk.org/jdk/pull/21040/files/aa22301c..fabcaebe

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

  Stats: 198321 lines in 1421 files changed: 184773 ins; 6839 del; 6709 mod
  Patch: https://git.openjdk.org/jdk/pull/21040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21040/head:pull/21040

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

From mbaesken at openjdk.org  Thu Oct 10 09:02:25 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Oct 2024 09:02:25 GMT
Subject: RFR: 8341820: Check return value of hcreate_r
Message-ID: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>

In symtab.c there is some coding where hcreate_r is used. We should check the return value of the call (previously there was some guarantee checking the return value but uncommented).

This has been discussed in the PR of [JDK-8341722](https://bugs.openjdk.org/browse/JDK-8341722) .

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

Commit messages:
 - JDK-8341820

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

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

From rcastanedalo at openjdk.org  Thu Oct 10 10:03:33 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 10 Oct 2024 10:03:33 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v39]
In-Reply-To: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
Message-ID: <ARBYJMJ_9fg6m5fGG6XyheX64J-YKzfyyBIhcX8Zzqs=.f7a44bfa-ca40-4ee7-b49c-4ba3161b0c0c@github.com>

On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase compiler code stubs size for indexOf intrinsic

Thanks @rkennke and @tstuefe for patiently addressing my comments. I have reviewed the HotSpot compiler parts of this changeset, except those in `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp` which should be reviewed by someone more familiar with the `indexOf` intrinsic implementation (@sviswa7 has suggested @vpaprotsk for this task). More specifically, my approval covers the following files/directories:


src/hotspot/cpu/aarch64 (excluding interpreter-only changes)
src/hotspot/cpu/x86 (excluding interpreter-only and c2_stubGenerator_x86_64_string.cpp changes)
src/hotspot/share/opto
src/hotspot/share/ci
src/hotspot/share/gc/{shared,x,z}/c2/{x,z}barrierSetC2.cpp
test/hotspot/jtreg/compiler


As I mentioned earlier, after the integration of this changeset and before compact headers can be considered non-experimental, I think C2's dependency on `klass_offset_in_bytes()` (when using compact headers) should be removed, and a more robust C2 model for klass pointer loading should be developed ([JDK-8340453](https://bugs.openjdk.org/browse/JDK-8340453)).

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

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2359713290

From sspitsyn at openjdk.org  Thu Oct 10 10:29:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Oct 2024 10:29:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <tDKSsTCaV04gGLI8ipFTwtIw-YMbbdxsP8llgnioA1k=.b43f02f2-bae9-4000-87d4-d5650fec2e1d@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

I've pushed two updates.
The first one addresses the suggestions from Leonid:
 - minor tweaks in new test
 - moved skipping hidden methods `yield()` and `yield0()` from `check_and_skip_hidden_frames()` to a separate function
 - explained in a comment of `JvmtiHandshake::execute()` why all VTMS transitions are disabled for platform thread
 - added extra safety/stability checks and a couple of asserts around calls to `check_and_skip_hidden_frames()`
 
 Second update fixes one more `NotifyFramePop` issue with the frames at the virtual thread start:
  - `enter()`, `enter0`, `VThreadContinuation$1.run()` and `VirtualThread.run()`
  
 This the bottom of stack trace from debugger:

  0: java/lang/VirtualThread: run(Ljava/lang/Runnable;)V
  1: java/lang/VirtualThread$VThreadContinuation$1: run()V
  2: jdk/internal/vm/Continuation: enter0()V
  3: jdk/internal/vm/Continuation: enter(Ljdk/internal/vm/Continuation;Z)V

The fix includes three parts:
- the `notifyJvmtiStart()`/`notifyJvmtiEnd()` notification calls are moved from `VirtualThread.run()` to the `VThreadContinuation$1.run()`
- the annotation `@JvmtiMountTransition` has been added to the `VThreadContinuation$1.run()`
- the `NotifyFramePop` is changed to return `JVMTI_ERRO_OPAQUE_FRAME` for frames with `enter()` and methods annotated with `@JvmtiMountTransition`

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

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2404706773

From aboldtch at openjdk.org  Thu Oct 10 11:59:24 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Oct 2024 11:59:24 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation [v2]
In-Reply-To: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
Message-ID: <h7J-SwU_EwWes2NwDpuH2Ihwv8DNoHYCtLPtfPSIvRk=.412c7bb4-588c-44fa-8999-9fba0e1fd88e@github.com>

> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
> 
> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
> 
> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> synchronized(o) {
>   deoptimize();
> }
> 
> got transformed to 
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> // synchronized(o) { Eliminated lock
>   deoptimize();
> // }
> 
> 
> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Remove @test id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21420/files
  - new: https://git.openjdk.org/jdk/pull/21420/files/e16bfde1..bfc5a349

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

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

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

From aboldtch at openjdk.org  Thu Oct 10 11:59:25 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Oct 2024 11:59:25 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation
In-Reply-To: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
Message-ID: <6l_D0sSCB0e_iT4BvSHilqJGEQo4rE5hGD9_SHibSX8=.776ebc6c-fc2c-4770-a25f-f0a59e335a14@github.com>

On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
> 
> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
> 
> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> synchronized(o) {
>   deoptimize();
> }
> 
> got transformed to 
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> // synchronized(o) { Eliminated lock
>   deoptimize();
> // }
> 
> 
> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

Ran through tier1-3 and stress tested escape analysis and lock elimination tests. 
Removed the `@test id=` as it gets propagated to the wrong place. The `@bug` is enough.

I'll integrate after I've gotten a review / re-review on the test configuration change.

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

PR Comment: https://git.openjdk.org/jdk/pull/21420#issuecomment-2404891138

From rkennke at openjdk.org  Thu Oct 10 13:27:23 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 10 Oct 2024 13:27:23 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
Message-ID: <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>

On Tue, 8 Oct 2024 17:20:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
> 
>  - Fix merge error
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

That is a big change - great work!
In this first batch I've reviewed:


src/hotspot/cpu
src/hotspot/gc/shared
src/hotspot/gc/shenandoah/c1
src/hotspot/gc/shenandoah/c2
src/hotspot/gc/shenandoah/heuristics
src/hotspot/gc/shenandoah/mode


I only have a few comments so far. Will review the remaining parts in separate batches.

src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp line 75:

> 73: 
> 74:   // Create a mask to test if the marking bit is set.
> 75:   // TODO: can we directly test if bit is set?

That comment here is quite justified, IMO. I'm pretty sure that we could test for the flag in a single instruction, instead of doing the and-cmp sequence and even allocating a new register. Unless of course when C1 LIR can't represent it. Have you tried to implement that and failed, and therefore remove the comment?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 96:

> 94:   size_t capacity    = _space_info->soft_max_capacity();
> 95:   size_t max_cset    = (size_t)((1.0 * capacity / 100 * ShenandoahEvacReserve) / ShenandoahEvacWaste);
> 96:   size_t free_target = (capacity * ShenandoahMinFreeThreshold) / 100 + max_cset;

Does re-arranging the math here risk overflow (e.g. on 32-bit)?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 79:

> 77: 
> 78: protected:
> 79:   static const uint Moving_Average_Samples = 10; // Number of samples to store in moving averages

I've never seen that style for constants in HotSpot before. I'd either make it MOVING_AVERAGE_SAMPLES or MovingAverageSamples. I think the latter is more prevalent, but I am not certain.

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2360208858
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795359413
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795377554
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795401675

From rkennke at openjdk.org  Thu Oct 10 13:27:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 10 Oct 2024 13:27:24 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
Message-ID: <coMcymMrKDj7JFvuSwRamr6_cSvNWRaXiTSKmauHTeg=.b47f58dd-3e36-4c08-8ba4-4e846502bb73@github.com>

On Thu, 10 Oct 2024 13:13:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 79:
> 
>> 77: 
>> 78: protected:
>> 79:   static const uint Moving_Average_Samples = 10; // Number of samples to store in moving averages
> 
> I've never seen that style for constants in HotSpot before. I'd either make it MOVING_AVERAGE_SAMPLES or MovingAverageSamples. I think the latter is more prevalent, but I am not certain.

Oh but I see that it's used in this source file. Hmm... So maybe stick with it for now and make a follow-up change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795404177

From pchilanomate at openjdk.org  Thu Oct 10 13:37:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 10 Oct 2024 13:37:10 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation [v2]
In-Reply-To: <h7J-SwU_EwWes2NwDpuH2Ihwv8DNoHYCtLPtfPSIvRk=.412c7bb4-588c-44fa-8999-9fba0e1fd88e@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
 <h7J-SwU_EwWes2NwDpuH2Ihwv8DNoHYCtLPtfPSIvRk=.412c7bb4-588c-44fa-8999-9fba0e1fd88e@github.com>
Message-ID: <pmagJCxrNJSzL8moN2WngFV1VRYZ5IlwzH2-RwSB4k4=.510a2eb5-2f54-4180-8fb6-5d50b0c13fbf@github.com>

On Thu, 10 Oct 2024 11:59:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>> 
>> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>> 
>> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
>> 
>> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
>> 
>> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
>> 
>> Object o = new Object();
>> synchronized(o) {
>>   o.wait(1);
>> }
>> synchronized(o) {
>>   deoptimize();
>> }
>> 
>> got transformed to 
>> 
>> Object o = new Object();
>> synchronized(o) {
>>   o.wait(1);
>> }
>> // synchronized(o) { Eliminated lock
>>   deoptimize();
>> // }
>> 
>> 
>> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
>> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @test id

Marked as reviewed by pchilanomate (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21420#pullrequestreview-2360354550

From rsunderbabu at openjdk.org  Thu Oct 10 14:27:08 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 10 Oct 2024 14:27:08 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

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

  addressing review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21423/files
  - new: https://git.openjdk.org/jdk/pull/21423/files/75001218..3e36b519

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

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

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

From sgehwolf at openjdk.org  Thu Oct 10 15:41:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 10 Oct 2024 15:41:14 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <cbeqn52d_TPX-3pwqn4WKrQXVXY_jUsvyfqVAEJxkm8=.b32d5a4f-2de5-4a83-a68b-2cd9cb434285@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2360759661

From aboldtch at openjdk.org  Thu Oct 10 17:06:16 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Oct 2024 17:06:16 GMT
Subject: RFR: 8341819: LightweightSynchronizer::enter_for races with
 deflation [v2]
In-Reply-To: <h7J-SwU_EwWes2NwDpuH2Ihwv8DNoHYCtLPtfPSIvRk=.412c7bb4-588c-44fa-8999-9fba0e1fd88e@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
 <h7J-SwU_EwWes2NwDpuH2Ihwv8DNoHYCtLPtfPSIvRk=.412c7bb4-588c-44fa-8999-9fba0e1fd88e@github.com>
Message-ID: <usj5lPzcCaN8n_EST2LilKO3NcQEzM2rfm-dcXtDtTs=.193e5dc4-fb9c-4e8b-9895-9417902c738e@github.com>

On Thu, 10 Oct 2024 11:59:24 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>> 
>> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>> 
>> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
>> 
>> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
>> 
>> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
>> 
>> Object o = new Object();
>> synchronized(o) {
>>   o.wait(1);
>> }
>> synchronized(o) {
>>   deoptimize();
>> }
>> 
>> got transformed to 
>> 
>> Object o = new Object();
>> synchronized(o) {
>>   o.wait(1);
>> }
>> // synchronized(o) { Eliminated lock
>>   deoptimize();
>> // }
>> 
>> 
>> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
>> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @test id

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21420#issuecomment-2405626337

From aboldtch at openjdk.org  Thu Oct 10 17:06:17 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Oct 2024 17:06:17 GMT
Subject: Integrated: 8341819: LightweightSynchronizer::enter_for races with
 deflation
In-Reply-To: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
References: <h8uvfhn7P2FFOBd2JNhFMLegsw-pf6THv_n3mArynFc=.33316b9e-fb41-4b45-93cc-7ed4c574ad15@github.com>
Message-ID: <Puothoz5nnjIB09k1SOjPFM1CukijLC5sZug-7LHi2Y=.0496bf27-a108-4c4b-be0f-7e7fc4b9315b@github.com>

On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a regression from [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state effectively blocking out deflation. `LightweightSynchronizer::enter_for` assumed this to be true. But when the `-UseObjectMonitorTable` path was added `// Do the old inflate and enter.` this is no longer true as it first inflates a monitor in an unlocked state and then tries to lock. We need to introduce a retry loop similar to what was used before [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
> 
> I propose we add this retry loop for both cases, to decouple the `LightweightSynchronizer::enter_for` from how lock elimination is done. With a retry loop, the only requirements for using `LightweightSynchronizer::enter_for` is that the Object locked on cannot have been locked on by another thread, i.e. there is no contention, but makes no assumptions on the interaction with the deflation thread.
> 
> For `-UseObjectMonitorTable` 7bdbe114eb57fe7310f9664a434c4d9203e656fc should be enough, as it will assist the deflating thread with deflation, so the second call must succeed. 
> 
> However `+UseObjectMonitorTable` cannot do this so it must wait for the deflating thread to make progress. But as mentioned above, this would only happen if partial lock elimination is performed. E.g.
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> synchronized(o) {
>   deoptimize();
> }
> 
> got transformed to 
> 
> Object o = new Object();
> synchronized(o) {
>   o.wait(1);
> }
> // synchronized(o) { Eliminated lock
>   deoptimize();
> // }
> 
> 
> As far as I can tell, this does not happen. But I do not want to couple lock elimination decision with `LightweightSynchronizer::enter_for`. So I propose a retry loop instead of just the two calls.
> After this change the only prerequisite for using `LightweightSynchronizer::enter_for` is that the object being synchronized can not have been reached by another JavaThread (except the deflating thread).  So there may never be contention, but there may be deflation.

This pull request has now been integrated.

Changeset: 6fad6af0
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fad6af0de5e749aa60038d70ae196b5f666286f
Stats:     18 lines in 2 files changed: 16 ins; 0 del; 2 mod

8341819: LightweightSynchronizer::enter_for races with deflation

Reviewed-by: pchilanomate, rkennke

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

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

From duke at openjdk.org  Thu Oct 10 18:38:13 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Thu, 10 Oct 2024 18:38:13 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <aOIDFcy6N_Ims-89p1mOMQMH2qLWtkX_DgJex-a0Ov0=.e4110110-039c-43bd-82f6-7ec445a502da@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
 <aOIDFcy6N_Ims-89p1mOMQMH2qLWtkX_DgJex-a0Ov0=.e4110110-039c-43bd-82f6-7ec445a502da@github.com>
Message-ID: <cBKpNihUe_TT_xIuTKJipGsD89_FuQg_AErlMg11qZk=.95fa1bfe-d261-4814-9eeb-68b0422e039a@github.com>

On Wed, 9 Oct 2024 19:45:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Have EventGeneratorLoop end after a more predictable duration
>
> Yes OEL was Oracle Linux:
> 
> Our CI tests with docker run on Oracle Linux 7, and they fail with elevated-true (i.e. with "--cap-add=NET_BIND_SERVICE").
> 
> Our CI runs with Oracle Linux 8 use podman and they are OK using "--cap-add=NET_BIND_SERVICE"

@kevinjwalls do you know which Docker version your OEL 7 tests use?

I'm not very familiar with the RPM-based world, but I set up an OEL 7 VM, got Docker 18.09 installed and trying to reproduce the test failure now. Just wondering if your CI uses the same one.


# yum list installed | grep docker-engine
docker-engine.x86_64                   18.09.1.ol-1.0.3.el7        @ol7_developer

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2405791086

From rkennke at openjdk.org  Thu Oct 10 19:27:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 10 Oct 2024 19:27:24 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
Message-ID: <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>

On Tue, 8 Oct 2024 17:20:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
> 
>  - Fix merge error
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

And here comes the first part of `src/hotspot/share/gc/shenandoah` review.

src/hotspot/share/gc/shenandoah/shenandoahAffiliation.hpp line 44:

> 42:     default:
> 43:       ShouldNotReachHere();
> 44:       return "?";

This return is unreachable code (according to my IDE)

src/hotspot/share/gc/shenandoah/shenandoahAffiliation.hpp line 58:

> 56:     default:
> 57:       ShouldNotReachHere();
> 58:       return "?";

Same.

src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 40:

> 38:   DIRTY_SCAN_OBJS     = 6,
> 39:   ALTERNATIONS        = 7,
> 40:   MAX_CARD_STAT_TYPE  = 8

Are the numerical values relevant or what is the reason to spell them out?

src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 46:

> 44:   CARD_STAT_SCAN_RS       = 0,
> 45:   CARD_STAT_UPDATE_REFS   = 1,
> 46:   MAX_CARD_STAT_LOG_TYPE  = 2

Same here?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 676:

> 674:     case ShenandoahAllocRequest::_alloc_shared_gc: {
> 675:       // Fast-path: try to allocate in the collector view first
> 676:       idx_t leftmost_collector = _partitions.leftmost(ShenandoahFreeSetPartitionId::Collector);

1. The curly bracing that starts at _alloc_plab and then again at _alloc_shared_gc is really really weird.
2. The block that is enclosed by the curly braces is really huge for a switch-case.
It probably looks better if the code can be factored out into a method and be called from the switch cases? I'm not sure if this is easy to do, because there are some returns and breaks sprinkled in the block, too. But this only makes it worse.

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2361030955
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795859909
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795860226
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795888252
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795888425
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1795936007

From cjplummer at openjdk.org  Thu Oct 10 20:02:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Oct 2024 20:02:09 GMT
Subject: RFR: 8341820: Check return value of hcreate_r
In-Reply-To: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
References: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
Message-ID: <HPa-cHEo3g131xuwBDhltHEdaluhv_FhaO71n5u1K1M=.e9cad980-7a41-4035-b265-ce2c2ea8f73a@github.com>

On Thu, 10 Oct 2024 08:57:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In symtab.c there is some coding where hcreate_r is used. We should check the return value of the call (previously there was some guarantee checking the return value but uncommented).
> 
> This has been discussed in the PR of [JDK-8341722](https://bugs.openjdk.org/browse/JDK-8341722) .

Looks good. Thanks for the cleanup.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21445#pullrequestreview-2361286987

From jlu at openjdk.org  Thu Oct 10 22:00:45 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 22:00:45 GMT
Subject: RFR: 8341794: Fix ExceptionOccurred in jdk.attach
Message-ID: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>

Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.

This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.attach_.
This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

JNI Docs - ExceptionCheck
> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Thu Oct 10 22:01:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Oct 2024 22:01:22 GMT
Subject: RFR: 8341797: Fix ExceptionOccurred in jdk.jdi
Message-ID: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>

Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.

This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.jdi_.
This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.

JNI Docs - ExceptionCheck
> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

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

Commit messages:
 - init

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

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

From mseledtsov at openjdk.org  Thu Oct 10 22:49:10 2024
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Thu, 10 Oct 2024 22:49:10 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <7qtN24O68lFXKIhmUZD4iCEn_NE9OcEPdL2Cn7iWITE=.3378efdd-d54c-4df5-b9e3-5114c9495930@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

Marked as reviewed by mseledtsov (Committer).

Changes look good to me. Thank you for making these changes.

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

PR Review: https://git.openjdk.org/jdk/pull/21423#pullrequestreview-2361544516
PR Comment: https://git.openjdk.org/jdk/pull/21423#issuecomment-2406168566

From amenkov at openjdk.org  Fri Oct 11 00:26:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 11 Oct 2024 00:26:09 GMT
Subject: RFR: 8341794: Fix ExceptionOccurred in jdk.attach
In-Reply-To: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
References: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
Message-ID: <-QGX3gDEa03o9FW936OO1AzYZPVDH9al0UWV93S8Dqk=.6d93d4e0-bfb1-44b7-bb4f-ba3e06136538@github.com>

On Thu, 10 Oct 2024 21:55:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.attach_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21459#pullrequestreview-2361673051

From amenkov at openjdk.org  Fri Oct 11 00:32:10 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 11 Oct 2024 00:32:10 GMT
Subject: RFR: 8341797: Fix ExceptionOccurred in jdk.jdi
In-Reply-To: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
References: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
Message-ID: <Dehg3g-iz61Yla0cgrH-DZw8-3L4TC9D9HN-J_2ucJ8=.6ce64167-fd63-4519-884f-373431266bbc@github.com>

On Thu, 10 Oct 2024 21:56:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.jdi_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21460#pullrequestreview-2361685169

From duke at openjdk.org  Fri Oct 11 00:50:09 2024
From: duke at openjdk.org (duke)
Date: Fri, 11 Oct 2024 00:50:09 GMT
Subject: RFR: 8341138: Rename jtreg property docker.support as
 container.support [v2]
In-Reply-To: <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
 <OXa3e1uxE9LmJ2xQWx8S6VdSOTHIPbMe5FO0mmngucM=.f1d39741-1866-476a-a0fd-eb2f3da9c9e4@github.com>
Message-ID: <eQ78vvDQeRdPWhkcQOE3irfp57ONh9Hb3pTV6g0XwDU=.ce77cdc4-6d65-4c73-9f7e-91932c03f7b5@github.com>

On Thu, 10 Oct 2024 14:27:08 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
>> 
>> Positive Testing:
>> tier1,tier2,tier3 - to check stability
>> tier5 - to run container tests
>> 
>> Negative Testing:
>> Ran the following groups in hosts where container is not present.
>> open/test/hotspot/jtreg/containers/
>> open/test/jdk/jdk/internal/platform/docker/
>> open/test/jdk/jdk/internal/platform/cgroup/
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comment

@rsunderbabu 
Your change (at version 3e36b519be6dfed513fbe867e3ec0f03e061eaa1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21423#issuecomment-2406315737

From cjplummer at openjdk.org  Fri Oct 11 03:49:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Oct 2024 03:49:09 GMT
Subject: RFR: 8341794: Fix ExceptionOccurred in jdk.attach
In-Reply-To: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
References: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
Message-ID: <l07bHUBuPi2rw5kNs2ERUkGbptK0HV6ac8ME7m776yQ=.ef60d5a6-7732-4f37-98c2-5cc4578eceb3@github.com>

On Thu, 10 Oct 2024 21:55:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.attach_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21459#pullrequestreview-2361906968

From cjplummer at openjdk.org  Fri Oct 11 03:50:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Oct 2024 03:50:10 GMT
Subject: RFR: 8341797: Fix ExceptionOccurred in jdk.jdi
In-Reply-To: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
References: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
Message-ID: <oACtfKJ9yywtPflA9kNm6o_WRJQ7sqZpnNLcJ1ahCRU=.0cbe016c-9bd9-46fc-a82c-2c3abc76db81@github.com>

On Thu, 10 Oct 2024 21:56:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.jdi_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21460#pullrequestreview-2361907548

From kbarrett at openjdk.org  Fri Oct 11 03:59:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Oct 2024 03:59:13 GMT
Subject: RFR: 8341722: Fix some warnings as errors when building on Linux
 with toolchain clang [v2]
In-Reply-To: <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
References: <7Ku9Im8ezr8pe8kNAqFBuJ2psZ7ZpYxB15icbON7-l4=.b30ffe03-1b45-41e4-a0f7-05141baf6cb1@github.com>
 <_xv74pf2blc3P7IPtDVOO7oDbH6rIZRh406FXP_cjZc=.5385eca4-86ff-4fae-be7c-59826dcfe305@github.com>
Message-ID: <WROL2RXymrN5wBbnQDZ3YfOFDLnSVvZZYV9kNziHUMY=.22a8cd29-f34d-4882-9bf4-27ac8e125988@github.com>

On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a few warnings as errors occurring when building on Linux with clang (clang15). Mostly these are some kind of 'unused' warnings.
>> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust gcc warning settings; bring back rslt

test/hotspot/gtest/runtime/test_os_linux.cpp line 366:

> 364:       os::pretouch_memory(heap, heap + size, os::vm_page_size());
> 365:     };
> 366:     auto useMemory = [heap](Thread*, int) {

Coming to this late, after the change has been integrated.

These lambdas should have been changed to use implicit reference capture
(`[&]`), per the style guide.

The change to the pretouch lambda actually makes things more difficult to
understand, since the outer `size` variable *is* referenced within the lambda
body.  This works because `size` is an integral constant initialized from a
constant expression, so does not need to be captured for the reference to
work. I'm guessing the clang warning had something to do with that, but it's
not mentioned in the JBS issue.  If implicit reference capture were used, the
referential transparency that comes with it would mean readers wouldn't need
to even know about that distinction.

I'll file an issue to change the capture lists.  I didn't find any other
explicit capture lists in HotSpot code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21407#discussion_r1796392834

From cjplummer at openjdk.org  Fri Oct 11 04:22:12 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Oct 2024 04:22:12 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v2]
In-Reply-To: <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
 <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
Message-ID: <oz7F7E-wrR9mx0n2aL8BGVUXYeluP3IQghQnuwEqEJM=.e9fdafc1-22b2-412b-b43a-bbf462c1009f@github.com>

On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
>  - Update comment about type name knowledge
>  - Test update
>  - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21040#pullrequestreview-2361929093

From aboldtch at openjdk.org  Fri Oct 11 06:43:33 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 11 Oct 2024 06:43:33 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas 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 12 additional commits since the last revision:

 - Merge tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - Add missing problem-listing
 - ... and 2 more: https://git.openjdk.org/jdk/compare/63794f5e...e58b4c5a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21401/files
  - new: https://git.openjdk.org/jdk/pull/21401/files/22c243a6..e58b4c5a

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

  Stats: 6773 lines in 133 files changed: 5327 ins; 455 del; 991 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

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

From mbaesken at openjdk.org  Fri Oct 11 07:53:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Oct 2024 07:53:12 GMT
Subject: RFR: 8336401: Remove the option onjcmd from the jdwp agent [v2]
In-Reply-To: <VRrXNAupKWfRz6R603yHDedooupj2bjkLDXt68m9DhQ=.88dfc7bc-2555-490e-b214-87015286fe47@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
 <VRrXNAupKWfRz6R603yHDedooupj2bjkLDXt68m9DhQ=.88dfc7bc-2555-490e-b214-87015286fe47@github.com>
Message-ID: <Pw6ByoInAkYQjyjrBk0-GULl-3vZQL4ZRlH6yuEzX70=.c4ddd8bb-0e28-4180-bb8e-dce3672b9447@github.com>

On Tue, 8 Oct 2024 06:58:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Remove the support for on-demand debugging via the onjcmd option.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use port 0 in TestAgentEvent

Thanks for doing the change + CSR, looks good!

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21387#pullrequestreview-2362178355

From lucy at openjdk.org  Fri Oct 11 08:13:11 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 11 Oct 2024 08:13:11 GMT
Subject: RFR: 8341820: Check return value of hcreate_r
In-Reply-To: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
References: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
Message-ID: <JA8LU7xW4gJeJIclm7RTuh93h_AVIxDYPaQ1P_HMK_E=.af06e1e0-79e7-4979-9f5b-15d8edcbb79b@github.com>

On Thu, 10 Oct 2024 08:57:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In symtab.c there is some coding where hcreate_r is used. We should check the return value of the call (previously there was some guarantee checking the return value but uncommented).
> 
> This has been discussed in the PR of [JDK-8341722](https://bugs.openjdk.org/browse/JDK-8341722) .

LGTM.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21445#pullrequestreview-2362219032

From mbaesken at openjdk.org  Fri Oct 11 08:25:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Oct 2024 08:25:17 GMT
Subject: RFR: 8341820: Check return value of hcreate_r
In-Reply-To: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
References: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
Message-ID: <aH6PyAD62346nYRXeuUld1fm6JbZGPHdNx-bc4qtN_E=.87ae83fa-47ec-457f-9615-70e510d5bcd1@github.com>

On Thu, 10 Oct 2024 08:57:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In symtab.c there is some coding where hcreate_r is used. We should check the return value of the call (previously there was some guarantee checking the return value but uncommented).
> 
> This has been discussed in the PR of [JDK-8341722](https://bugs.openjdk.org/browse/JDK-8341722) .

Hi Lutz and Chris, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/21445#issuecomment-2406886245

From mbaesken at openjdk.org  Fri Oct 11 08:25:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 11 Oct 2024 08:25:17 GMT
Subject: Integrated: 8341820: Check return value of hcreate_r
In-Reply-To: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
References: <LISXgfRLSEp9Zg4WJRn7Rbe3E5jsJpU3sAIk5BuPlgM=.d91bea35-cd45-464d-a79e-0c827b976d95@github.com>
Message-ID: <kGBt_JAAE_AFvjhrQteZ3nlRusweSaTG1Q4V4B7XGYg=.40311436-e7f5-4ece-8b45-157d75170f9b@github.com>

On Thu, 10 Oct 2024 08:57:44 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In symtab.c there is some coding where hcreate_r is used. We should check the return value of the call (previously there was some guarantee checking the return value but uncommented).
> 
> This has been discussed in the PR of [JDK-8341722](https://bugs.openjdk.org/browse/JDK-8341722) .

This pull request has now been integrated.

Changeset: 7c0dbf8e
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c0dbf8e9c69d51aa8e06305e4483002116019f4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8341820: Check return value of hcreate_r

Reviewed-by: cjplummer, lucy

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

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

From duke at openjdk.org  Fri Oct 11 08:40:10 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Fri, 11 Oct 2024 08:40:10 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <S7fAw6bi8o--7jzB55cJhAosQ2orGRshSmeXEdCGtUU=.83e0f1a9-ce17-4f8f-a642-decaf2b66853@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

I had to change SELinux to permissive to get the Docker tests to work at all in the OEL 7 VM (and bind-mounting to work in general for Docker containers). Maybe there are ways to give just the right permissions.


# grep ^SELINUX= /etc/sysconfig/selinux
SELINUX=permissive


How is SELinux configured in your CI? I would not be surprised if it's related to that, but as it stands, I have not been able to reproduce any failure in my VM.

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

PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2406915951

From sspitsyn at openjdk.org  Fri Oct 11 09:18:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Oct 2024 09:18:23 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning
Message-ID: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>

There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.

Testing:
 - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
 - TBD: mach5 tiers 1-6

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

Commit messages:
 - fixed trailing spaces in new test
 - 8340698: JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning

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

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

From sspitsyn at openjdk.org  Fri Oct 11 09:26:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Oct 2024 09:26:42 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  minor comment tweak

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/773b5d68..c68625be

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

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

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

From rkennke at openjdk.org  Fri Oct 11 12:28:18 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 11 Oct 2024 12:28:18 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
Message-ID: <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>

On Tue, 8 Oct 2024 17:20:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
> 
>  - Fix merge error
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

I reviewed the rest of `src/hotspot/shared/gc/shenandoah`. I tried to find places where this could affect performance or even correctness of single-gen Shenandoah, but could not find any (altough, some places are a bit shady and hard to figure out, e.g. ShFreeSet).

Overall I only have a couple of comments.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 579:

> 577:   st->print("Status: ");
> 578:   if (has_forwarded_objects())                 st->print("has forwarded objects, ");
> 579:   if (is_concurrent_mark_in_progress())        st->print("marking, ");

What is this printing when not running with generational mode?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 535:

> 533:   ShenandoahPacer*           pacer()             const { return _pacer;             }
> 534: 
> 535:   ShenandoahPhaseTimings*      phase_timings()   const { return _phase_timings;     }

The indentation is off here.

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 335:

> 333: uint ShenandoahHeap::get_object_age(oop obj) {
> 334:   // This is impossible to do unless we "freeze" ABA-type oscillations
> 335:   // With Lilliput, we can do this more easily.

The comment about Lilliput can be removed. Since we only return the actual age when the mark is not displaced, we already to the correct thing. With lightweight-locking, the mark can never be displaced, and this code should just work.

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 396:

> 394: }
> 395: 
> 396: inline bool ShenandoahHeap::is_old(oop obj) const {

What is the difference between this method and the above is_in_old()? Why does it need to check that active generation is young?

src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.hpp line 28:

> 26: #define SHARE_GC_SHENANDOAH_SHENANDOAHMMUTRACKER_HPP
> 27: 
> 28: #include "runtime/mutex.hpp"

I think you don't use Mutex in this file.

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2362458572
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796745606
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796795684
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796806016
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796807913
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796848150

From rkennke at openjdk.org  Fri Oct 11 15:18:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 11 Oct 2024 15:18:25 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
Message-ID: <_1_RPbV4VVoczxDhQYp967iOM37EHh3ZcK5b8dvKrQU=.1b9556a6-81d3-428d-8593-bd4cdced44de@github.com>

On Tue, 8 Oct 2024 17:20:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
> 
>  - Fix merge error
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>    
>    Reviewed-by: kdnilsen
>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>    
>    Reviewed-by: kdnilsen, ysr
>  - Merge
>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>    
>    Reviewed-by: kdnilsen
>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>    
>    Reviewed-by: kdnilsen, shade, ysr
>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1

I looked at the remaining changes, it's mostly tests. Only some minor comments/requests on those.

test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java line 100:

> 98: 
> 99: /*
> 100:  * @test id=generational

You are making a test configuration and call it 'generational' but then one of the two run configurations doesn't actually run with generational mode. You probably want to separate the two?

test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java line 163:

> 161:         final int min = 0;
> 162:         final int max = 384 * 1024;
> 163:         // Each allocated int array is assumed to consume 16 bytes for alignment and header, plus

With the upcoming 'compact headers' it's going to be only 12 bytes. If that matters, then the actual number should perhaps be a constant? Preexisting and not relevant for this PR, though.

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocLargeObj.java line 1:

> 1: /*

Why are you removing the test?

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocLargerThanHeap.java line 1:

> 1: /*

And this test?

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 1:

> 1: /*

Or is this new test subsuming several old tests?

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

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2362848068
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796980759
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1796983485
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797098313
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797098581
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797099580

From wkemper at openjdk.org  Fri Oct 11 21:11:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:11:25 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <_1_RPbV4VVoczxDhQYp967iOM37EHh3ZcK5b8dvKrQU=.1b9556a6-81d3-428d-8593-bd4cdced44de@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <_1_RPbV4VVoczxDhQYp967iOM37EHh3ZcK5b8dvKrQU=.1b9556a6-81d3-428d-8593-bd4cdced44de@github.com>
Message-ID: <fW88Zw-E1Qn13Bld1tENYqIHhtFK8-kK_9tJUXsbE9I=.8d6bdae9-2252-41fd-92c0-c85cdac2b917@github.com>

On Fri, 11 Oct 2024 15:13:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 1:
> 
>> 1: /*
> 
> Or is this new test subsuming several old tests?

Correct, we rolled the `TestAlloc` tests into one file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797425083

From wkemper at openjdk.org  Fri Oct 11 21:17:28 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:17:28 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <coMcymMrKDj7JFvuSwRamr6_cSvNWRaXiTSKmauHTeg=.b47f58dd-3e36-4c08-8ba4-4e846502bb73@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
 <coMcymMrKDj7JFvuSwRamr6_cSvNWRaXiTSKmauHTeg=.b47f58dd-3e36-4c08-8ba4-4e846502bb73@github.com>
Message-ID: <BqqLUcQv5c1hYnw-djrhPuiYLcHPW4xehxoL59otYMA=.08a60cc7-b1d6-4bcd-9837-03be7af629ec@github.com>

On Thu, 10 Oct 2024 13:14:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 79:
>> 
>>> 77: 
>>> 78: protected:
>>> 79:   static const uint Moving_Average_Samples = 10; // Number of samples to store in moving averages
>> 
>> I've never seen that style for constants in HotSpot before. I'd either make it MOVING_AVERAGE_SAMPLES or MovingAverageSamples. I think the latter is more prevalent, but I am not certain.
>
> Oh but I see that it's used in this source file. Hmm... So maybe stick with it for now and make a follow-up change?

Yes. I agree this is idiosyncratic formatting for the rest of HotSpot, but it is consistent with pre-existing constants in this file:

  static const intx Concurrent_Adjust   = -1; // recover from penalties
  static const intx Degenerated_Penalty = 10; // how much to penalize average GC duration history on Degenerated GC
  static const intx Full_Penalty        = 20; // how much to penalize average GC duration history on Full GC

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797428779

From wkemper at openjdk.org  Fri Oct 11 21:20:37 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:20:37 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
Message-ID: <mbqd_3S_N2z-b7NqIWPnl1U0za1AwWY5lXUZK-KgWoI=.10c8544d-b66a-44c5-add5-2924776e7b29@github.com>

On Fri, 11 Oct 2024 10:14:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 579:
> 
>> 577:   st->print("Status: ");
>> 578:   if (has_forwarded_objects())                 st->print("has forwarded objects, ");
>> 579:   if (is_concurrent_mark_in_progress())        st->print("marking, ");
> 
> What is this printing when not running with generational mode?

It will print "young marking". We can change this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797430904

From wkemper at openjdk.org  Fri Oct 11 21:24:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:24:27 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
Message-ID: <KQqx9s1UaQvKGVdbT7DfqovPsSDciqK-Swy5TTqNc1s=.dda14ecb-8c8a-4089-85fa-cad144b3f533@github.com>

On Fri, 11 Oct 2024 11:01:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 535:
> 
>> 533:   ShenandoahPacer*           pacer()             const { return _pacer;             }
>> 534: 
>> 535:   ShenandoahPhaseTimings*      phase_timings()   const { return _phase_timings;     }
> 
> The indentation is off here.

I'll fix this, but I secretly don't like this style of formatting because it is slightly tedious to maintain. It also suggests that these methods are somehow grouped and formatted together for a reason beyond aesthetics.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 396:
> 
>> 394: }
>> 395: 
>> 396: inline bool ShenandoahHeap::is_old(oop obj) const {
> 
> What is the difference between this method and the above is_in_old()? Why does it need to check that active generation is young?

This is just a bad, confusing method name. I'll fix this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797432875
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797433441

From jlu at openjdk.org  Fri Oct 11 21:33:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 11 Oct 2024 21:33:31 GMT
Subject: Integrated: 8341794: Fix ExceptionOccurred in jdk.attach
In-Reply-To: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
References: <WEHSS-KBcDmI6FDJAJ6zmvfgTN34HHY93ultd-ileMg=.20f6cae3-7a71-436f-b9f4-409c8aa146fb@github.com>
Message-ID: <M53QaHLJqNf5PILqi7LIpQCBxKz-mVAVqhpsuBqQN3E=.eaa7f130-564c-4a2e-bd60-087e332bc91e@github.com>

On Thu, 10 Oct 2024 21:55:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.attach_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

This pull request has now been integrated.

Changeset: c4965d9b
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4965d9b135b58e0b3604bc1cc60978ad4c8c11b
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8341794: Fix ExceptionOccurred in jdk.attach

Reviewed-by: amenkov, cjplummer

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

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

From jlu at openjdk.org  Fri Oct 11 21:35:25 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 11 Oct 2024 21:35:25 GMT
Subject: Integrated: 8341797: Fix ExceptionOccurred in jdk.jdi
In-Reply-To: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
References: <gi3sl_CPCRcUYGYk4P5U1dW7_CYgcCmun4Shu1Mk4rE=.edcc6ed0-e39d-426a-822f-a4e77db02408@github.com>
Message-ID: <UkVwe7zNKZTBtHmB9lSXFdR4WSbILRmvxMNqmCNwVpA=.6afa88c9-1c3f-4ec0-8fa7-870720fda21c@github.com>

On Thu, 10 Oct 2024 21:56:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is part of the bigger umbrella bug: https://bugs.openjdk.org/browse/JDK-8341542.
> 
> This fixes incorrect usage of `jthrowable ExceptionOccurred(JNIEnv *env)` within _jdk.jdi_.
> This corrects instances where the return value is being treated as a boolean. Such occurrences are replaced with `jboolean ExceptionCheck(JNIEnv *env)`.
> 
> JNI Docs - ExceptionCheck
>> We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object. ... Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

This pull request has now been integrated.

Changeset: 2db33971
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2db3397187563d1821d24578247f764c372fbb4b
Stats:     11 lines in 2 files changed: 0 ins; 0 del; 11 mod

8341797: Fix ExceptionOccurred in jdk.jdi

Reviewed-by: amenkov, cjplummer

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

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

From wkemper at openjdk.org  Fri Oct 11 21:36:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:36:27 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
Message-ID: <HMSP0scm_Gfhhy8xaDhTpLmqxj-bMrbfzHj-8x7_Fxk=.ef4ff564-6779-422a-acae-5a4c5162e53b@github.com>

On Thu, 10 Oct 2024 17:44:03 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/shenandoahAffiliation.hpp line 58:
> 
>> 56:     default:
>> 57:       ShouldNotReachHere();
>> 58:       return "?";
> 
> Same.

https://bugs.openjdk.org/browse/JDK-8341992

> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 335:
> 
>> 333: uint ShenandoahHeap::get_object_age(oop obj) {
>> 334:   // This is impossible to do unless we "freeze" ABA-type oscillations
>> 335:   // With Lilliput, we can do this more easily.
> 
> The comment about Lilliput can be removed. Since we only return the actual age when the mark is not displaced, we already to the correct thing. With lightweight-locking, the mark can never be displaced, and this code should just work.

https://bugs.openjdk.org/browse/JDK-8341992

> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.hpp line 28:
> 
>> 26: #define SHARE_GC_SHENANDOAH_SHENANDOAHMMUTRACKER_HPP
>> 27: 
>> 28: #include "runtime/mutex.hpp"
> 
> I think you don't use Mutex in this file.

https://bugs.openjdk.org/browse/JDK-8341992

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797440111
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797439856
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797439708

From wkemper at openjdk.org  Fri Oct 11 21:36:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 21:36:27 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <KQqx9s1UaQvKGVdbT7DfqovPsSDciqK-Swy5TTqNc1s=.dda14ecb-8c8a-4089-85fa-cad144b3f533@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
 <KQqx9s1UaQvKGVdbT7DfqovPsSDciqK-Swy5TTqNc1s=.dda14ecb-8c8a-4089-85fa-cad144b3f533@github.com>
Message-ID: <avAI9bydxLsKZJVUU89s3hJCI3e95Y33ypRkEuZGxBE=.cdc38975-4d14-47f4-a201-807070b53e76@github.com>

On Fri, 11 Oct 2024 21:20:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 535:
>> 
>>> 533:   ShenandoahPacer*           pacer()             const { return _pacer;             }
>>> 534: 
>>> 535:   ShenandoahPhaseTimings*      phase_timings()   const { return _phase_timings;     }
>> 
>> The indentation is off here.
>
> I'll fix this, but I secretly don't like this style of formatting because it is slightly tedious to maintain. It also suggests that these methods are somehow grouped and formatted together for a reason beyond aesthetics.

https://bugs.openjdk.org/browse/JDK-8341992

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797439929

From wkemper at openjdk.org  Fri Oct 11 22:03:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 22:03:26 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
Message-ID: <1tM_l9mquiouiroTulNDRfVposOwRRVmj18YD_WJU6I=.20e1a171-4438-417f-af58-18e2ed57d125@github.com>

On Thu, 10 Oct 2024 12:48:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp line 75:
> 
>> 73: 
>> 74:   // Create a mask to test if the marking bit is set.
>> 75:   // TODO: can we directly test if bit is set?
> 
> That comment here is quite justified, IMO. I'm pretty sure that we could test for the flag in a single instruction, instead of doing the and-cmp sequence and even allocating a new register. Unless of course when C1 LIR can't represent it. Have you tried to implement that and failed, and therefore remove the comment?

@shipilev and I looked at this: https://github.com/openjdk/jdk/pull/19180#discussion_r1609666303. The performance change was insignificant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797456666

From ysr at openjdk.org  Fri Oct 11 22:17:28 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Oct 2024 22:17:28 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
Message-ID: <V6vSlviRiPnhKtFAFhl19jMWyTRUCTjTwp9gp42TgyE=.7b5da064-1d5e-4f22-a3fb-fa5c6cd0d9a7@github.com>

On Thu, 10 Oct 2024 18:07:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 40:
> 
>> 38:   DIRTY_SCAN_OBJS     = 6,
>> 39:   ALTERNATIONS        = 7,
>> 40:   MAX_CARD_STAT_TYPE  = 8
> 
> Are the numerical values relevant or what is the reason to spell them out?

Not needed; explicit enumeration values can be removed.

> src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 46:
> 
>> 44:   CARD_STAT_SCAN_RS       = 0,
>> 45:   CARD_STAT_UPDATE_REFS   = 1,
>> 46:   MAX_CARD_STAT_LOG_TYPE  = 2
> 
> Same here?

Yes, same; explicit enumeration values can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797462093
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797462886

From cjplummer at openjdk.org  Fri Oct 11 23:16:20 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Oct 2024 23:16:20 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
Message-ID: <xL0CLfS6kApk2ez5VIqsGf1YTtAZbIhAwWEj8Mpqlqs=.e4fdb376-5af3-4ada-8512-c8a3c8d95c98@github.com>

On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas 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 12 additional commits since the last revision:
> 
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - Add missing problem-listing
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/df0ae672...e58b4c5a

The serviceability related changes look good. I suppose the 6 or so SA bugs filed against the non-generational ZGC can be closed out. I have a note to myself to go through them and close if appropriate. We have [JDK-8307393](https://bugs.openjdk.org/browse/JDK-8307393) filed for the lack of SA support for generational ZGC, and that is probably the only SA ZGC related issue we need to keep around.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2363665123

From wkemper at openjdk.org  Fri Oct 11 23:34:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Oct 2024 23:34:32 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
Message-ID: <9VnBxOMfOYEdW6nHhKxSvAtURKeC3a8GfpVPo-g7cr8=.dffb958c-a71d-4fd5-9319-eabff1f6c2f9@github.com>

On Thu, 10 Oct 2024 18:47:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 676:
> 
>> 674:     case ShenandoahAllocRequest::_alloc_shared_gc: {
>> 675:       // Fast-path: try to allocate in the collector view first
>> 676:       idx_t leftmost_collector = _partitions.leftmost(ShenandoahFreeSetPartitionId::Collector);
> 
> 1. The curly bracing that starts at _alloc_plab and then again at _alloc_shared_gc is really really weird.
> 2. The block that is enclosed by the curly braces is really huge for a switch-case.
> It probably looks better if the code can be factored out into a method and be called from the switch cases? I'm not sure if this is easy to do, because there are some returns and breaks sprinkled in the block, too. But this only makes it worse.

https://bugs.openjdk.org/browse/JDK-8342001

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1797493799

From duke at openjdk.org  Sat Oct 12 02:48:25 2024
From: duke at openjdk.org (duke)
Date: Sat, 12 Oct 2024 02:48:25 GMT
Subject: Withdrawn: 8328866: Add raw monitor rank support to the debug agent
In-Reply-To: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
References: <93YjmODwCGoXcsJIoNu3Ot5ckIegnS0pmhmavIAHNhQ=.69c012c0-584d-42d1-b469-5aa36cd7252e@github.com>
Message-ID: <eL_sTe0na_Rgf1uWkCvJmBnT0T6Q9s65HC5Y6qptjKA=.f6c6df3a-bc9d-4805-8ce9-106ab160d87f@github.com>

On Wed, 1 May 2024 21:32:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> This PR adds ranked monitor support to the debug agent. The debug agent has a large number of monitors, and it's really hard to know which order to grab them in, and for that matter which monitors might already be held at any given moment. By imposing a rank on each monitor, we can check to make sure they are always grabbed in the order of their rank. Having this in place when I was working on [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made it much easier to detect a deadlock that was occuring, and the reason for it. That's what motivated me to do this work
> 
> There were 2 or 3 minor rank issues discovered as a result of these changes. I also learned a lot about some of the more ugly details of the locking support in the process.
> 
> Tested with the following on all supported platforms and with virtual threads:
> 
> com/sun/jdi
> vmTestbase/nsk/jdi
> vmTestbase/nsk/jdb
> vmTestbase/nsk/jdwp 
> 
> Still need to run tier2 and tier5.
> 
> Details of the changes follow in the first comment.

This pull request has been closed without being integrated.

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

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

From rsunderbabu at openjdk.org  Sat Oct 12 03:28:17 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sat, 12 Oct 2024 03:28:17 GMT
Subject: Integrated: 8341138: Rename jtreg property docker.support as
 container.support
In-Reply-To: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
References: <VXLFe8nIH_Bg6tjmD9GA-c1SISSiP_hKOq0Gmvq2GZA=.785d3ba6-316c-49b4-af40-c57106950616@github.com>
Message-ID: <j3p52OjHQUJMh9WD-RGUOS2cth5xigSxmQy0xUVQS80=.9fc9039c-8edc-4291-a1db-2b5c0a00559b@github.com>

On Wed, 9 Oct 2024 14:50:30 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> The System property "docker.support" defined in VMProps gives a wrong impression that it is tied to docker alone. The property is common for any container runtime. Hence, it needs to be renamed as "container.support".
> 
> Positive Testing:
> tier1,tier2,tier3 - to check stability
> tier5 - to run container tests
> 
> Negative Testing:
> Ran the following groups in hosts where container is not present.
> open/test/hotspot/jtreg/containers/
> open/test/jdk/jdk/internal/platform/docker/
> open/test/jdk/jdk/internal/platform/cgroup/

This pull request has now been integrated.

Changeset: 41ee582d
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41ee582df8c65f2f26b21e46784cf0bc4ece0585
Stats:     54 lines in 26 files changed: 6 ins; 0 del; 48 mod

8341138: Rename jtreg property docker.support as container.support

Reviewed-by: sgehwolf, mseledtsov

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

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

From sspitsyn at openjdk.org  Sat Oct 12 11:09:17 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 12 Oct 2024 11:09:17 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <51lZUKmNd7ohM7HvCR4NbAc2rYFn96n9ToHcQYORNuw=.e8f916cc-41d7-412d-b769-ec0efd520e8f@github.com>

On Fri, 30 Aug 2024 00:07:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

This is nice fix, thank you for doing this!
I still need one more pass on the Windows `AttachListener` part and hope to complete it early next week.

src/hotspot/share/services/attachListener.cpp line 649:

> 647: 
> 648:   return true;
> 649: }

Nit: This function is too big. I'd suggest to split it to make more readable. For example, the lines 596-648 can be moved to new function which is called by the `AttachOperation::read_request()'.

src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line 46:

> 44: 
> 45:     private volatile long hProcess;     // handle to the process
> 46:     private int ver = VERSION_1;        // updated by detectVersion on attach

Nit: The comment is not fully accurate as the result returned by the `detectVersion()` is stored in this private field by the `VirtualMachineImpl` constructor.

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

PR Review: https://git.openjdk.org/jdk/pull/20782#pullrequestreview-2363889264
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1797683041
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1797678822

From stooke at openjdk.org  Sat Oct 12 17:31:49 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Sat, 12 Oct 2024 17:31:49 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v18]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <GYSVpmwbzOYdJWUEGq2-_lMLM5DJQ6wZabHOhcK28NE=.8860a4af-b912-47ed-a19f-ec8346b44344@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  odd github behaviour

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/9fe1466b..673269c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=16-17

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

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

From azafari at openjdk.org  Sat Oct 12 18:45:14 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Sat, 12 Oct 2024 18:45:14 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
Message-ID: <R_WaDca9nkuBz7qbRVCynovFC2dFyeHnY62Nbkqqd9A=.668f1165-4c34-4beb-9b95-33808d52ed74@github.com>

On Wed, 2 Oct 2024 13:28:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - 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>

Just an important test or comparison is needed here. Do you have any comparison of  the performance before and after this PR change set? Even if no degrading is expected, better to test it.

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2408656738

From stooke at openjdk.org  Sun Oct 13 06:09:52 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Sun, 13 Oct 2024 06:09:52 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v19]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <kUXpVxxcUiBHxqUM6u1kAZYBeywEuEOSikQgtoA9TzA=.46a979af-5385-46da-9b98-b9d91cfeb632@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  spelling mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/673269c9..b1893035

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=17-18

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

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

From stooke at openjdk.org  Sun Oct 13 15:38:49 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Sun, 13 Oct 2024 15:38:49 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  clean up test code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/b1893035..b7e6043f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=18-19

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

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

From iklam at openjdk.org  Mon Oct 14 06:30:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 06:30:55 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v14]
In-Reply-To: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
Message-ID: <n5nKbRETxgCw_GnrS_45VQUHaDK5uSi_Fa1cL7Ml4JM=.c74b5fdb-4919-41fd-80d2-b90a54dca993@github.com>

> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Overview**
> 
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
> 
> **All-or-nothing Loading**
> 
> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exact same set of modules are visible whe...

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

 - Added more exclusions to hotspot_aot_classlinking test group, as these tests disable full-module-graph
 - Merge branch 'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into jep-483-step-03-8329706-implement-xx-aot-class-linking
 - Merge branch 'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into jep-483-step-03-8329706-implement-xx-aot-class-linking
 - Merge branch 'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into jep-483-step-03-8329706-implement-xx-aot-class-linking
 - @dholmes-ora comments
 - @dholmes-ora comments
 - Fixed ZERO build
 - minor comment fix
 - @ashu-mehra comment: move code outside of call_initPhase2(); also renamed BOOT/BOOT2 to BOOT1/BOOT2 and refactored code related to AOTLinkedClassCategory
 - @ashu-mehra reviews
 - ... and 8 more: https://git.openjdk.org/jdk/compare/c068db8e...02ac6d6e

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

Changes: https://git.openjdk.org/jdk/pull/20843/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=13
  Stats: 1795 lines in 47 files changed: 1638 ins; 57 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/20843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20843/head:pull/20843

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

From iklam at openjdk.org  Mon Oct 14 07:19:03 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 14 Oct 2024 07:19:03 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v15]
In-Reply-To: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
Message-ID: <1ZXms0ZIxS7YIAqTp97N51dVk8iNpwuBm_zLPO6qqYw=.18911399-dfb8-4293-bba4-57e643561065@github.com>

> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Overview**
> 
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
> 
> **All-or-nothing Loading**
> 
> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exact same set of modules are visible whe...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Missed one file from last commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20843/files
  - new: https://git.openjdk.org/jdk/pull/20843/files/02ac6d6e..22c47d33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=13-14

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

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

From stooke at openjdk.org  Mon Oct 14 10:34:15 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 14 Oct 2024 10:34:15 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v13]
In-Reply-To: <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <DnxU95E6xPzeplFJjqm9uBz9uVtPrabtyBDMHCSY0DA=.96dfd1b4-8464-4c54-8d12-8289260f754e@github.com>
 <JIZECiR3qnin5JvsmlpMvFgkn-e7oQgoblW1-ChUw2E=.f5d04581-cac3-44ab-b09d-b52703ca0b13@github.com>
Message-ID: <kcgwrevwamjJ1F5SzEu3wg-v0zsJTJ0tsLzMGK3K-hQ=.c0aa1396-7ea3-4c69-b9e7-d07c19080f88@github.com>

On Mon, 23 Sep 2024 02:13:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete commented out code
>
> Changes requested by dholmes (Reviewer).

Hello, @dholmes-ora , could you please take another look?  I've responded to your concerns about the macOS-specific tests, but I don't know if you feel my response is adequate.

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

PR Comment: https://git.openjdk.org/jdk/pull/20683#issuecomment-2410764298

From rkennke at openjdk.org  Mon Oct 14 16:58:27 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 14 Oct 2024 16:58:27 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <1tM_l9mquiouiroTulNDRfVposOwRRVmj18YD_WJU6I=.20e1a171-4438-417f-af58-18e2ed57d125@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
 <1tM_l9mquiouiroTulNDRfVposOwRRVmj18YD_WJU6I=.20e1a171-4438-417f-af58-18e2ed57d125@github.com>
Message-ID: <uZUQVcDqmjsuXAcUNYJ3zUgqkufbC6CNmhIcXRg6ov4=.5dfd1d85-2c61-434a-924a-e8d50221148d@github.com>

On Fri, 11 Oct 2024 22:00:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp line 75:
>> 
>>> 73: 
>>> 74:   // Create a mask to test if the marking bit is set.
>>> 75:   // TODO: can we directly test if bit is set?
>> 
>> That comment here is quite justified, IMO. I'm pretty sure that we could test for the flag in a single instruction, instead of doing the and-cmp sequence and even allocating a new register. Unless of course when C1 LIR can't represent it. Have you tried to implement that and failed, and therefore remove the comment?
>
> @shipilev and I looked at this: https://github.com/openjdk/jdk/pull/19180#discussion_r1609666303. The performance change was insignificant.

ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1799832437

From mdoerr at openjdk.org  Mon Oct 14 17:40:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 17:40:38 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
 <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
 <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
 <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <9F4j9U7srQ_aLXdOairjcjGy9Rm-gO8MXPCrqz03iec=.00254e94-dbcc-49ce-a0de-3b72cd2e2b4e@github.com>

On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Indeed, I could re-enable all tests in:
>>> 
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>>> ```
>>> 
>>> but unfortunately not those others:
>>> 
>>> ```
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>>> ```
>>> 
>>> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
>>> 
>>> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.
>> 
>> @rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine:
>> 
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> - test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
>> 
>> Here are the failure details:
>> 
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>> 
>> 1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
>>            - Failed comparison: [found] 0 >= 1 [given]
>>            - No nodes matched!
>>          * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 >= 1 [given]
>>            - No nodes matched!
>> 
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java:
>> 
>> 1) Method "public static void compiler.c2.irTests.TestVectorizati...
>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
> 
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?

@rkennke: I have a PPC64 implementation: https://github.com/TheRealMDoerr/jdk/commit/6722f8be9a0940fab6417d4de58ec1538c436702
Do you want to include it? Should we also ask s390 and riscv folks?

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2411867295

From rkennke at openjdk.org  Mon Oct 14 19:11:30 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 14 Oct 2024 19:11:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v11]
In-Reply-To: <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <DUgk6HT_Zk5KnbmAd_HzrJi4B8D1J-uuoAGzReWyI8s=.6c04f90a-bf1d-49af-a31d-5224973952d4@github.com>
 <YTte6oY9EeAPHxzzOndL8M202wY91SbeaYC4hPva0W0=.caf00270-89c7-44b0-ab88-a970fb8e840d@github.com>
 <kzodWwxj5qdAqPYcP2s4k2QTXqjju2H6Iftu7dojezk=.1f72fc31-94ba-4017-b330-c8688a8d39a4@github.com>
 <hkGaBWSugvpV0PgoR9rnutHCgQzkeXv1ctH7QwV3zK0=.204737d5-fadb-410a-8891-7db59d36830f@github.com>
 <shoDPnL4nQyaYX4xy-WyzQ7CwsoCbAeCE3c755CkE1o=.caf940aa-5fbb-4cb5-a4a2-68a2452ffe1b@github.com>
 <TBZCkcFNNnEvat7TBnRkqUPo4Y5TEe1L0iUZ9loD7DI=.39c0249c-f6b2-45c8-b7c8-9e2c9c1b7a99@github.com>
 <toUdNzwkdDAQDltc4_t6wI06bCE-EHzpIs_t-arIwNY=.7d9ef348-0033-4268-9ed1-7c183855521f@github.com>
Message-ID: <JCG6RiKoWCBiqIqi-DsgwqdFE1X_9KrJH1Sqnpdl-2E=.72327548-6e1c-44df-ae77-0fcdb3b92c32@github.com>

On Tue, 1 Oct 2024 15:46:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> Indeed, I could re-enable all tests in:
>>> 
>>> ```
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>>> test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
>>> ```
>>> 
>>> but unfortunately not those others:
>>> 
>>> ```
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
>>> > > > test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
>>> ```
>>> 
>>> I think the issue with all of them is that vectorization in those scenarios only works when the operations inside the loop start at an array index that addresses an element at 8-byte-aligned offset.
>>> 
>>> I have filed https://bugs.openjdk.org/browse/JDK-8340010 to track it.
>> 
>> @rkennke A test run of the current changeset in our internal CI system revealed that the following tests fail (because of missing vectorization) when using `-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:UseSSE=N` with `N <= 3` on an Intel Xeon Platinum 8358 machine:
>> 
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java
>> - test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
>> - test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
>> 
>> Here are the failure details:
>> 
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
>> 
>> 1) Method "public static void compiler.c2.irTests.TestVectorizationNotRun.test(byte[],long[])" - [Failed IR rules: 1]:
>>    * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#LOAD_VECTOR_L#_", ">=1", "_#STORE_VECTOR#_", ">=1"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"
>>      > Phase "PrintIdeal":
>>        - counts: Graph contains wrong number of nodes:
>>          * Constraint 1: "(\\d+(\\s){2}(LoadVector.*)+(\\s){2}===.*vector[A-Za-z]\[2\]:\{long\})"
>>            - Failed comparison: [found] 0 >= 1 [given]
>>            - No nodes matched!
>>          * Constraint 2: "(\\d+(\\s){2}(StoreVector.*)+(\\s){2}===.*)"
>>            - Failed comparison: [found] 0 >= 1 [given]
>>            - No nodes matched!
>> 
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java:
>> 
>> 1) Method "public static void compiler.c2.irTests.TestVectorizati...
>
>> test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationNotRun.java:
> 
> I think I would disable the tests for now. Is there a good way to say 'run this when UCOH is off OR UseSSE>3?

> @rkennke: I have a PPC64 implementation: [TheRealMDoerr at 6722f8b](https://github.com/TheRealMDoerr/jdk/commit/6722f8be9a0940fab6417d4de58ec1538c436702) Do you want to include it? Should we also ask s390 and riscv folks?

AFAIK, @Hamlin-Li is working on the RISCV port. Not sure who would do s390. If it's available before intergration, I'll include it, but I'll not wait for it.

Thanks for the PPC64 port, I'll include it in this PR!

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2412025660

From amenkov at openjdk.org  Mon Oct 14 20:32:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 14 Oct 2024 20:32:26 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v2]
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <aBNfwFar-hmcV8CQ1WD0a_DFT1uBKzVKzvGQJdmWC_E=.a104b5de-1c27-4e88-a68e-0bd4b5884d7f@github.com>

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

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/20782/files
  - new: https://git.openjdk.org/jdk/pull/20782/files/fd52c130..2e904c58

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

  Stats: 85 lines in 3 files changed: 45 ins; 33 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20782/head:pull/20782

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

From amenkov at openjdk.org  Mon Oct 14 20:32:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 14 Oct 2024 20:32:26 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v2]
In-Reply-To: <51lZUKmNd7ohM7HvCR4NbAc2rYFn96n9ToHcQYORNuw=.e8f916cc-41d7-412d-b769-ec0efd520e8f@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <51lZUKmNd7ohM7HvCR4NbAc2rYFn96n9ToHcQYORNuw=.e8f916cc-41d7-412d-b769-ec0efd520e8f@github.com>
Message-ID: <oP63Lki07hy7ORWTCKedgfTBMRD0M8NRk5ElhS6qZZU=.3d469b39-af78-47a8-890e-c350379469a3@github.com>

On Sat, 12 Oct 2024 11:04:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/hotspot/share/services/attachListener.cpp line 649:
> 
>> 647: 
>> 648:   return true;
>> 649: }
> 
> Nit: This function is too big. I'd suggest to split it to make more readable. For example, the lines 596-648 can be moved to new function which is called by the `AttachOperation::read_request()'.

Done

> src/jdk.attach/windows/classes/sun/tools/attach/VirtualMachineImpl.java line 46:
> 
>> 44: 
>> 45:     private volatile long hProcess;     // handle to the process
>> 46:     private int ver = VERSION_1;        // updated by detectVersion on attach
> 
> Nit: The comment is not fully accurate as the result returned by the `detectVersion()` is stored in this private field by the `VirtualMachineImpl` constructor.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1800056341
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1800056007

From mdoerr at openjdk.org  Mon Oct 14 21:49:28 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 14 Oct 2024 21:49:28 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v39]
In-Reply-To: <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
Message-ID: <LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>

On Tue, 8 Oct 2024 16:30:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase compiler code stubs size for indexOf intrinsic

Thanks!
@offamitkumar: It could still be done after this PR is integrated, but I guess you want to provide an s390 implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2412394373

From amenkov at openjdk.org  Tue Oct 15 00:21:41 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 00:21:41 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v3]
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  renamed JVM_EnqueueOperation2
  
  renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20782/files
  - new: https://git.openjdk.org/jdk/pull/20782/files/2e904c58..1fed4ea6

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

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

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

From duke at openjdk.org  Tue Oct 15 01:25:22 2024
From: duke at openjdk.org (duke)
Date: Tue, 15 Oct 2024 01:25:22 GMT
Subject: Withdrawn: 8337276: jcmd man page update for PID in output filenames
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <hzThfqtM85sbKpxK8_AFGSj07UGciAMe0j-U7KnuKLM=.1c1332d8-68fc-418c-a075-149a58bf5778@github.com>

On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

This pull request has been closed without being integrated.

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

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

From mli at openjdk.org  Tue Oct 15 08:09:36 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 15 Oct 2024 08:09:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <cL1TRIR8QmiIxhVU8LmxcEjUcneCNyLOh7ik4fgmIcM=.abc5dea2-6d92-4b6e-9e3f-01137441d02e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
 <cL1TRIR8QmiIxhVU8LmxcEjUcneCNyLOh7ik4fgmIcM=.abc5dea2-6d92-4b6e-9e3f-01137441d02e@github.com>
Message-ID: <G60MN3iR1XqQsIpQ-u-TUb5UK7DmCkOOIZ8_UnTgS64=.d0da6080-2991-4578-af68-453ffc63f2ef@github.com>

On Thu, 19 Sep 2024 15:01:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>>  - review feedback
>
> In both aarch64.ad and x86_64.ad, `MachUEPNode::format` might need some change accordingly?

> AFAIK, @Hamlin-Li is working on the RISCV port. Not sure who would do s390. If it's available before intergration, I'll include it, but I'll not wait for it.

Thanks! We're having some internal (riscv specific) discussion & review, should be able to provide the patch soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2413178574

From amitkumar at openjdk.org  Tue Oct 15 08:14:30 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 15 Oct 2024 08:14:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v39]
In-Reply-To: <LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <q4sTPbMm-cK1O35GhIbRytiakYgyKJYrBhotG_Kwn2o=.02620a61-e96d-4c93-af80-d27a61dd9ee7@github.com>
 <LjXNg7ygXw6KlgE0O5mMhgJ2IpNSpcZV1VKvF-p3qdQ=.608e20a4-25a8-4b9d-acaa-39eead7c4617@github.com>
Message-ID: <ay-vYduVhGNK9HQodtCnP9Awa_NXaGRtGYOh55KqgxU=.a4ba42c8-eafa-4517-87a8-a92bcbc398be@github.com>

On Mon, 14 Oct 2024 21:47:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>@offamitkumar: It could still be done after this PR is integrated, but I guess you want to provide an s390 implementation.

I haven't looked into it yet. I am looking into other issues for now, but I will if I can get time to work on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2413190779

From kevinw at openjdk.org  Tue Oct 15 08:20:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 15 Oct 2024 08:20:18 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <AR1GjRf-lX13uCeYFIlMHlVBUTB3_cdL_9bLwEd6fQU=.15ece98b-cac3-4df4-a6e6-adb2a19efcd3@github.com>

On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

My plan is to come back and finalize this change once https://github.com/openjdk/jdk/pull/21040 is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/20401#issuecomment-2413202369

From kevinw at openjdk.org  Tue Oct 15 08:21:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 15 Oct 2024 08:21:18 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v2]
In-Reply-To: <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
 <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
Message-ID: <H05-PMxAqhj5POrTy0I2asAJF5Io4DdRYYsSNdqyIMo=.276e36fe-71d5-428d-b177-e7712f273f4e@github.com>

On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
>  - Update comment about type name knowledge
>  - Test update
>  - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

Thanks Chris.

Hoping to get a second approval.
Would be great to get this change done, then I can go back and know that the man page change in https://github.com/openjdk/jdk/pull/20401
will be correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/21040#issuecomment-2413205144

From egahlin at openjdk.org  Tue Oct 15 08:34:13 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Oct 2024 08:34:13 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v2]
In-Reply-To: <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
 <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
Message-ID: <vzxTjiFQrnLhaHdaPsKUbM523csXni0PSU3nSi0wSqk=.ce6d98f9-02f9-4e73-bb04-57001c317f0a@github.com>

On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
>  - Update comment about type name knowledge
>  - Test update
>  - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21040#pullrequestreview-2368548822

From kevinw at openjdk.org  Tue Oct 15 08:34:14 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 15 Oct 2024 08:34:14 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v2]
In-Reply-To: <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
 <LO0OwXg7OKt-HH1ohu7L9XXEGkD4Vvujg_qJwxGpc0E=.68dee81a-ed57-4f95-81b7-5ca80df8a591@github.com>
Message-ID: <MGKQ00MQvpRRMyySmeRYVuFRJSQN5he1TEekLa2XJp0=.b729355e-10f5-46ce-8327-a409f5815386@github.com>

On Thu, 10 Oct 2024 08:51:38 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
>> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".
>
> 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 four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
>  - Update comment about type name knowledge
>  - Test update
>  - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

Thanks Erik!

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

PR Comment: https://git.openjdk.org/jdk/pull/21040#issuecomment-2413233734

From rkennke at openjdk.org  Tue Oct 15 08:46:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 08:46:57 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v40]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <LMXcf9mNlOcl32Ii2GjKD3MU85-5ShuLCQ_R_53tKB8=.1f6fd73c-99a2-4c70-a925-55aa52904d9e@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  PPC64 implementation of Compact Object Headers (JEP 450)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/b289ef88..6722f8be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=39
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=38-39

  Stats: 161 lines in 9 files changed: 95 ins; 39 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From kevinw at openjdk.org  Tue Oct 15 08:53:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 15 Oct 2024 08:53:39 GMT
Subject: RFR: 8338603: DiagnosticCommandMBean operations should standardize
 types for parameters [v3]
In-Reply-To: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
Message-ID: <uEO9ohG_7gmDXMCYzPi_1Ff0gt3k5FmftCfU38giTx8=.66ead888-92fe-4b81-a607-190826ede355@github.com>

> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".

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

 - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
 - Merge remote-tracking branch 'upstream/master' into 8338603_dcmd_mbean_types
 - Update comment about type name knowledge
 - Test update
 - 8338603: DiagnosticCommandMBean operations should standardize types for parameters.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21040/files
  - new: https://git.openjdk.org/jdk/pull/21040/files/fabcaebe..70312190

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

  Stats: 14306 lines in 284 files changed: 12064 ins; 1035 del; 1207 mod
  Patch: https://git.openjdk.org/jdk/pull/21040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21040/head:pull/21040

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

From rkennke at openjdk.org  Tue Oct 15 09:02:16 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 09:02:16 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v41]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <JBrhBOknUeYekenNA45sQtigIIHUEQaKpCvdBIZVdeA=.73bbcac9-af12-4672-92e0-cbe9b6921490@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:

 - Merge tag 'jdk-24+19' into JDK-8305895-v4
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - PPC64 implementation of Compact Object Headers (JEP 450)
 - Increase compiler code stubs size for indexOf intrinsic
 - Fix include guards
 - Improve PSParallelCompact::fill_dense_prefix_end() even more
 - Re-enable indexOf intrinsic for compact headers
 - Rename nklass in aarch64
 - Fix comment
 - Rename nklass in x86 code
 - Fix header < 16 bytes in indexOf intrinsic, by @sviswa7
 - ... and 80 more: https://git.openjdk.org/jdk/compare/e7c5bf45...86f94fee

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

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=40
  Stats: 4865 lines in 205 files changed: 3383 ins; 818 del; 664 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From sgehwolf at openjdk.org  Tue Oct 15 09:43:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 09:43:02 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v10]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <_wzqCdQ-RVPJsfS1tjWnorQJpINjfP3RA4O14xNMGdU=.4a9b6e43-d199-4dcf-851e-9c297b58e647@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 35 commits:

 - 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
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - ... and 25 more: https://git.openjdk.org/jdk/compare/521effe0...03699b08

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

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=09
  Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 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 sspitsyn at openjdk.org  Tue Oct 15 09:55:15 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 09:55:15 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v3]
In-Reply-To: <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
Message-ID: <7nf9YVsVg_UA_kD85dcBd8tT0_J_maZ5H-WGBEgWdbU=.685a1387-c66e-4514-8c74-1da1bf4bac57@github.com>

On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed JVM_EnqueueOperation2
>   
>   renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)

src/hotspot/os/windows/attachListener_windows.cpp line 40:

> 38: // executes a small stub generated by the client. The stub invokes the
> 39: // JVM_EnqueueOperation or JVM_EnqueueOperation_v2 function which checks the operation parameters
> 40: // and enqueues the operation request to the queue serviced by the attach listener. The thread created by

Nit: Just a suggestion to simplify this line of comment a little bit:
  // and enqueues the operation request for the attach listener. The thread created by

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1800830693

From sspitsyn at openjdk.org  Tue Oct 15 10:05:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 10:05:14 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v3]
In-Reply-To: <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
Message-ID: <yf04TLG-7_kdS5fmHfcR4qIWrGDMGqLma6FwaAEAkOI=.d96ff9db-a3d8-4f07-a1f4-43252c5b5715@github.com>

On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed JVM_EnqueueOperation2
>   
>   renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)

src/hotspot/os/windows/attachListener_windows.cpp line 108:

> 106:                             size,
> 107:                             &nread,
> 108:                             nullptr);   // not overlapped

Nit: Missed space after `fsuccess` at line 104.
       Also, there is not cast `(DWORD)size` at line 106 as it is done in the `WriteFile()` call at line 118.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1800848373

From sspitsyn at openjdk.org  Tue Oct 15 10:14:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 10:14:13 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v3]
In-Reply-To: <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
Message-ID: <cj6GbSxw0ZkFTSulCvt91mHxvKwg49B7RL0-tMEApck=.a21d0969-3fb7-4086-821c-eaf9f24d78e9@github.com>

On Tue, 15 Oct 2024 00:21:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed JVM_EnqueueOperation2
>   
>   renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)

I've posted some nits and one questions.
Otherwise, this change looks good to me.

src/hotspot/os/windows/attachListener_windows.cpp line 194:

> 192:   }
> 193:   const char* arg(int i) const {
> 194:     return (i >= 0 && AttachOperation::arg_count_max) ? _arg[i] : nullptr;

Nit: Dot is not needed at the end of comment at line 140.
Q: Should the condition at line 194 be modified as below:
   ```return (i >= 0 && i < AttachOperation::arg_count_max) ? _arg[i] : nullptr;```

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

PR Review: https://git.openjdk.org/jdk/pull/20782#pullrequestreview-2368827594
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1800860402

From rsunderbabu at openjdk.org  Tue Oct 15 10:16:38 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 15 Oct 2024 10:16:38 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver
Message-ID: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>

Passing "-Xmx1g -Xcomp" to the LingeredApp.
Testing: tier1

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

Commit messages:
 - start the LingeredApp with jvm options

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

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

From rkennke at openjdk.org  Tue Oct 15 10:47:55 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 15 Oct 2024 10:47:55 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v42]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix aarch64.ad

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/86f94fee..005498b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=41
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=40-41

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

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

From kevinw at openjdk.org  Tue Oct 15 10:53:15 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 15 Oct 2024 10:53:15 GMT
Subject: Integrated: 8338603: DiagnosticCommandMBean operations should
 standardize types for parameters
In-Reply-To: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
References: <xIViDjMqN7MGl1ZnGKObmmE-nYtdtn6mcAFWPzrxNmw=.f88d6563-1345-4271-869b-a31e50440014@github.com>
Message-ID: <3_K1g-JQznKDxhE2V1oEGiE5WKM9R__ullYvDxd73c8=.6712eeb9-d159-4040-a94a-082a4d282772@github.com>

On Tue, 17 Sep 2024 14:10:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> DiagnosticCommandImpl should only publish parameter types in a known standard set, and use "STRING" on anything else.
> e.g. We can say "FILE" in the help output for jcmd, as that's for humans, but the MBean parameter info should contain "STRING".

This pull request has now been integrated.

Changeset: df7d6e08
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df7d6e081ff9513fbd6cff5d033a307e6798418b
Stats:     58 lines in 2 files changed: 50 ins; 0 del; 8 mod

8338603: DiagnosticCommandMBean operations should standardize types for parameters

Reviewed-by: cjplummer, egahlin

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

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

From tschatzl at openjdk.org  Tue Oct 15 11:28:31 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 15 Oct 2024 11:28:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v8]
In-Reply-To: <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <J0g0PSye768dhN3JoXFsZ6FivocNBLPmHNtRUCOmLTw=.5756c64a-4763-4727-9637-ba3fe7b9b17d@github.com>
 <6usTXIvS83aO2VzX5xu2EnXlpIJ8YbfrWS6b3EI0MhE=.0e8cc603-0cd3-4bd9-b309-55e4dd0f0cb0@github.com>
Message-ID: <N0f3YokOST3MTXR_iRwPjQGBEz15Pb9KB1zffJJwFuI=.d7ae3343-2fdd-43e0-855d-de8975603732@github.com>

On Mon, 9 Sep 2024 11:53:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Try to avoid lea in loadNklass (aarch64)
>>  - Fix release build error
>
> src/hotspot/share/oops/klass.hpp line 169:
> 
>> 167:                                 // contention that may happen when a nearby object is modified.
>> 168:   AccessFlags _access_flags;    // Access flags. The class/interface distinction is stored here.
>> 169:                                 // Some flags created by the JVM, not in the class file itself,
> 
> Suggestion:
> 
>   markWord _prototype_header;   // Used to initialize objects' header with compact headers.
> 
> 
> Maybe some comment why this is an instance member.

>@tschatzl I just found your comment here, and I'm not sure what you mean, tbh. The prototype_header is a member of Klass because with compact headers, it encodes that Klass in the prototype header. Note that there is planned follow-up work to remove that field and encode the Klass* on the allocation path. https://bugs.openjdk.org/browse/JDK-8341703

You explained what I had wanted to see here - why do we need a per-klass prototype header, because the markWord contains it ;)
Given that it is going away, I retract this comment and the request can be resolved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1800983876

From mullan at openjdk.org  Tue Oct 15 13:03:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
Message-ID: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>

This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.

NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.

The code changes can be broken down into roughly the following categories:

1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.

There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 

Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most familiar with.

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

Commit messages:
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - fix setOpenURIHandler docs
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Fix whitespace
 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove windows-specific policy file as it is no longer needed.
 - clientlibs: Updated Problemlist JBS ID for javax/swing/JPopupMenu/6694823/bug6694823.java
 - Merge
 - ... and 73 more: https://git.openjdk.org/jdk/compare/a601cd2e...d05122fb

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338411
  Stats: 63777 lines in 1825 files changed: 935 ins; 59236 del; 3606 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From liach at openjdk.org  Tue Oct 15 13:03:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 15 Oct 2024 13:03:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

@seanjmullan I think you can use many lines of command in one github comment, like

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563

From dfuchs at openjdk.org  Tue Oct 15 15:19:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Impressive work. I had a look at everything source in `net`, `logging`, `jmx` and `httpclient`.

Mostly good, but I was surprised to see an explicit new `throw new SecurityException()` in `java.util.logging`; Also JMX still supports authentication and coarse authorisation, which means that `SecurityException` can still be thrown by the `JMXAuthenticator` / `MBeanServerAccessController` on the server side and thrown on the client side. I have made some suggestions.

src/java.base/share/classes/java/net/URLClassLoader.java line 667:

> 665:      * @param codesource the codesource
> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
> 667:      * @return the permissions for the codesource

Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:

> 2428:     @Deprecated(since="17", forRemoval=true)
> 2429:     public void checkAccess() {
> 2430:         throw new SecurityException();

Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:

> 157:      * is specified for the MBean.
> 158:      * @throws SecurityException if the client does not have permission
> 159:      * to perform this operation.

Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.

So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.

An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:

> 65:      *
> 66:      * @exception SecurityException if the server cannot authenticate the user
> 67:      * with the provided credentials.

Should this be reverted? Authentication has not been removed.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:

> 223:      *
> 224:      * @exception SecurityException if the connection cannot be made
> 225:      * for security reasons.

I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

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

Changes requested by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369425602
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801215698
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801291195
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801341618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801357691
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801362306

From alanb at openjdk.org  Tue Oct 15 15:24:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 15 Oct 2024 15:24:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>

On Tue, 15 Oct 2024 14:27:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
> 
>> 2428:     @Deprecated(since="17", forRemoval=true)
>> 2429:     public void checkAccess() {
>> 2430:         throw new SecurityException();
> 
> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?

This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801415455

From dfuchs at openjdk.org  Tue Oct 15 15:36:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 15:36:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
Message-ID: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>

On Tue, 15 Oct 2024 15:21:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/LogManager.java line 2430:
>> 
>>> 2428:     @Deprecated(since="17", forRemoval=true)
>>> 2429:     public void checkAccess() {
>>> 2430:         throw new SecurityException();
>> 
>> Though this method is no longer called in the JDK, this is a change of behaviour that could affect subclasses of `LogManager`, or code using the `LogManager` that might still be calling this method. This method is deprecated for removal, and degrading it to always throw an exception is a logical step prior to removing it. However, I wonder if this shouldn't better be done separately, outside of this JEP?
>
> This is forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.

OK

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801445724

From ihse at openjdk.org  Tue Oct 15 15:42:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 15 Oct 2024 15:42:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <V_CgYKM3b79sS7MTegDSIISOX92kZVccIePJlJ4hFzk=.b9cabb49-8f94-4d8b-80a5-c8cd66a2821d@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369826643

From duke at openjdk.org  Tue Oct 15 15:55:17 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 15:55:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
Message-ID: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>

On Tue, 15 Oct 2024 15:33:03 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is a bit of forced move. Same thing with Thread.checkAccess and ThreadGroup.checkAccess that also have to be re-specified to throw unconditionally. They are called out in the CSR.
>
> OK

While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:


if (System.getSecurityManager() != null) {
    foo.checkAccess();
}


I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.

But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801484176

From mullan at openjdk.org  Tue Oct 15 16:17:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 16:17:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
Message-ID: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>

On Tue, 15 Oct 2024 15:52:13 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> OK
>
> While I disagree with this change on the principle of "the system should operate as if no security manager were installed", the workaround for callers is actually rather simple:
> 
> 
> if (System.getSecurityManager() != null) {
>     foo.checkAccess();
> }
> 
> 
> I assume the justification for having these methods throw is consistency with the `check*` methods defined on `SecurityManager`. I agree that those methods should throw, because nobody should be handling instances of `SecurityManager` after this change. However, having other `checkAccess` methods throw (as opposed to being a no-op, as they would behave previously when no security manager is installed) doesn't really fulfill this spirit in my opinion.
> 
> But since the workaround is so simple, it doesn't really matter. It would be different if we (library authors) would have to resort to MR JARs for example, but that is not the case.

While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801518838

From sgehwolf at openjdk.org  Tue Oct 15 16:37:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:37:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:


        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
        ...
        }


Intentional?

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2369966554

From duke at openjdk.org  Tue Oct 15 16:37:22 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 15 Oct 2024 16:37:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
Message-ID: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>

On Tue, 15 Oct 2024 16:14:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.

It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.

These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).

Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801549133

From dfuchs at openjdk.org  Tue Oct 15 16:44:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 15 Oct 2024 16:44:16 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <00frHPVuBzy1HhWEnmBtfSS4CeXN3uOVVilYbvntplY=.40626317-3ede-4a7f-b906-a8fa7829a418@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

@jerboaa  Yes - this is intentional:
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414512674

From sgehwolf at openjdk.org  Tue Oct 15 16:57:21 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 15 Oct 2024 16:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <OEIkKR6Sw3EXctdW1_XBHuxNnO0-bFrnDSF6LXNXH4E=.34bb911a-bde4-4c35-bdd0-27558d8ed812@github.com>
Message-ID: <kht8vPv-muz8n2rWPcwE6tr_AIfxSHjqRdW85e7qxQA=.3f1ea0f1-51d8-4b31-ace9-74e00b0f0152@github.com>

On Tue, 15 Oct 2024 16:34:40 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Drive-by comment: `java.lang.StackWalker` still has some `checkPermission()` calls that uses:
> 
> 
>         SecurityManager sm = System.getSecurityManager();
>         if (sm != null) {
>         ...
>         }
> 
> 
> Intentional?

> @jerboaa Yes - this is intentional:
> 
> > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).

OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2414541204

From mullan at openjdk.org  Tue Oct 15 17:04:25 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 17:04:25 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
Message-ID: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>

On Tue, 15 Oct 2024 16:34:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally
>> permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>
>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
> 
> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
> 
> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
> 
> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.

I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801595566

From erikj at openjdk.org  Tue Oct 15 17:52:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8aC3jj6-F-URh3DOk-64i-0FSHKwpUX7gPAvP70FUnI=.b8b29107-9a65-403f-8292-1613a401a3d3@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370152926

From cjplummer at openjdk.org  Tue Oct 15 17:52:22 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 17:52:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kAgds4PDaZp8jva1ib1vtT7Tcj2kOOf3SbiOkHnYIZE=.2c46f0ff-0a3d-43a7-900e-482ab38f03ce@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

jdk.jdi and jdk.attach changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370157272

From coleenp at openjdk.org  Tue Oct 15 18:51:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Oct 2024 18:51:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <fedkR8waMXM0YzqN0-EynQLWQ03lqgpylDzmPbAXOP0=.a774e759-073e-4e77-85de-49c69acf4904@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

HotSpot changes look great.  Will clean out the rest in [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370289526

From naoto at openjdk.org  Tue Oct 15 18:51:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 15 Oct 2024 18:51:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <4WtQzf1WGGjNSzOuxPNvYOub8uuVyYhaad13b4RfMDI=.d7e704b1-68af-4ddd-b221-77b76c179f98@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

This is a great work! I looked through the following areas that relate to i18n/charset/console/javatime, and they all look good to me.

src/java.base/share/classes/java/util/Locale.java
src/java.base/share/classes/java/util/ResourceBundle.java
src/java.base/share/classes/java/util/TimeZone.java
src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java

test/jdk/java/io/Console/
test/jdk/java/nio/charset/spi/
test/jdk/java/time/nontestng/java/time/chrono/
test/jdk/java/util/PluggableLocale/
test/jdk/java/util/ResourceBundle/
test/jdk/java/util/TimeZone/
test/jdk/java/util/spi/ResourceBundleControlProvider/
test/jdk/sun/nio/cs/
test/jdk/sun/util/locale/provider/

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370292817

From duke at openjdk.org  Tue Oct 15 19:08:13 2024
From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=)
Date: Tue, 15 Oct 2024 19:08:13 GMT
Subject: RFR: 8341482: Attach API access to /proc filesystem should use
 doPrivileged [v2]
In-Reply-To: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
Message-ID: <7w6YHW02YtcgYw4giNMNCrlG7_ubcjyXE8ucigWmbHI=.7b2ec962-7b79-451b-8776-1035cfaf651e@github.com>

On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

Thanks @larry-cable for looking into this!

The following test passes on my Ubuntu 24.04 with this PR at least.

`TestJcmdWithSideCar` with Docker:

make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=docker"


`TestJcmdWithSideCar` with Podman:

make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="JAVA_OPTIONS=-Djdk.test.container.command=podman"



make test TEST="jtreg:test/hotspot/jtreg/containers"
make test TEST="jtreg:test/hotspot/jtreg/serviceability"


FWIW, the `SecurityManager` PR (#21498) has been opened now. Ideally we would get this one in before it's merged.

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 70:

> 68:     @FunctionalInterface
> 69:     private interface IOFunction<T, R> {
> 70:       public R apply(T t) throws IOException;

Minor nit, indentation is a bit off compared to the rest of the file:

Suggestion:

        public R apply(T t) throws IOException;

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 76:

> 74:     private static <R> R filesFunctionPrivileged(IOFunction<Path, R> function, final Path path, Supplier<R> def) throws IOException {
> 75:       try {
> 76:         return AccessController.doPrivileged((PrivilegedExceptionAction<R>) () -> function.apply(path));

Ditto:

Suggestion:

          return AccessController.doPrivileged((PrivilegedExceptionAction<R>) () -> function.apply(path));

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

Marked as reviewed by slovdahl at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/21312#pullrequestreview-2370283806
PR Review Comment: https://git.openjdk.org/jdk/pull/21312#discussion_r1801747382
PR Review Comment: https://git.openjdk.org/jdk/pull/21312#discussion_r1801750306

From mchung at openjdk.org  Tue Oct 15 19:36:24 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Oct 2024 19:36:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Source changes in `java.base/java/lang/**`, `java.management`, and `jdk.management` module look good.  Also hotspot change.

src/java.base/share/classes/java/lang/SecurityManager.java line 72:

> 70:     private static class StackWalkerHolder {
> 71:         static final StackWalker STACK_WALKER =
> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);

Suggestion:

            StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));


Method info is not needed.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370337536
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801781277

From cjplummer at openjdk.org  Tue Oct 15 20:42:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 20:42:11 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver
In-Reply-To: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
Message-ID: <fbXMxg5WtVPEgJEh1nnRAdicB11B1Tv0MeXudDYNSq4=.15e29223-99f6-4d13-9a91-6b2eaadfd590@github.com>

On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1

We have 3 processes here:

1. The test.
2. The SA Debuggee process spawned by the test (LingeredApp)
3. The SA "tool", also spawned by the test.

(1) and (2) will automatically get the default test args, which will include -Xcomp if it is a -Xcomp test task. (3) will not get the default test args since it is spawned with createLimitedTestJavaProcessBuilder(), which is likely what we want. The only process that needs to be run with -Xcomp (and any other test args) is (2) the debuggee process, but I don't see why we don't just allow it to get -Xcomp when run as part of a -Xcomp test task, and not have -Xcomp otherwise.

It doesn't appear that -Xcomp on the debuggee is a requirement for this test, because in the past it has not been explicitly run with -Xcomp. The changes in the PR get rid of test runs where the debuggee does not use -Xcmp, and also continue to force -Xcomp on the test process, which is unnecessary.

If we really only want the debuggee run with -Xcomp, then we should probably limit this test to only support -Xcomp test runs. So that means adding `@requires vm.compMode == "Xcomp"`. It also means getting rid of -Xcomp elsewhere in the test. I'm not sure of the reason for `-Xmx1g`. Maybe @tkrodriguez can explain.

I think another options is to have the test explicitly launch the debuggee with -Xcomp as is done in this PR, but also add `@requires vm.flagless`. @lmesnik?

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

PR Review: https://git.openjdk.org/jdk/pull/21519#pullrequestreview-2370566945

From wkemper at openjdk.org  Tue Oct 15 20:49:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Oct 2024 20:49:24 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <OrqMuPkkk9F5W2zYe_QYaKzm-pJD9U_Y8knJHqzzN-Y=.3abef30c-03b3-4bc0-a0ca-aed4a54617fc@github.com>
Message-ID: <7Y0f1A161C8p_W13beNZEsIGywt8i5JQz9LS-LQabQ4=.cb780e1a-7519-4a9b-9c63-c65898de6749@github.com>

On Thu, 10 Oct 2024 12:58:56 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 96:
> 
>> 94:   size_t capacity    = _space_info->soft_max_capacity();
>> 95:   size_t max_cset    = (size_t)((1.0 * capacity / 100 * ShenandoahEvacReserve) / ShenandoahEvacWaste);
>> 96:   size_t free_target = (capacity * ShenandoahMinFreeThreshold) / 100 + max_cset;
> 
> Does re-arranging the math here risk overflow (e.g. on 32-bit)?

https://bugs.openjdk.org/browse/JDK-8342239

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1801956645

From wkemper at openjdk.org  Tue Oct 15 20:54:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Oct 2024 20:54:18 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <V6vSlviRiPnhKtFAFhl19jMWyTRUCTjTwp9gp42TgyE=.7b5da064-1d5e-4f22-a3fb-fa5c6cd0d9a7@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <BqVG4w78ZKCAL7acQX42dPJwjDuAYv41pZnzwgupv1M=.69f4f8a4-1262-4002-a58f-ed9c5660772c@github.com>
 <V6vSlviRiPnhKtFAFhl19jMWyTRUCTjTwp9gp42TgyE=.7b5da064-1d5e-4f22-a3fb-fa5c6cd0d9a7@github.com>
Message-ID: <Ii8-wuHr3qir9XW9Nb4Kv18M1Dh4d_fbmo1IGZC0NmA=.5f174cf3-038a-4bd5-84d2-4b5bda54c2ff@github.com>

On Fri, 11 Oct 2024 22:12:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 40:
>> 
>>> 38:   DIRTY_SCAN_OBJS     = 6,
>>> 39:   ALTERNATIONS        = 7,
>>> 40:   MAX_CARD_STAT_TYPE  = 8
>> 
>> Are the numerical values relevant or what is the reason to spell them out?
>
> Not needed; explicit enumeration values can be removed.

https://github.com/openjdk/shenandoah/pull/514

>> src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 46:
>> 
>>> 44:   CARD_STAT_SCAN_RS       = 0,
>>> 45:   CARD_STAT_UPDATE_REFS   = 1,
>>> 46:   MAX_CARD_STAT_LOG_TYPE  = 2
>> 
>> Same here?
>
> Yes, same; explicit enumeration values can be removed.

https://github.com/openjdk/shenandoah/pull/514

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1801975222
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1801975588

From cjplummer at openjdk.org  Tue Oct 15 20:57:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 20:57:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
Message-ID: <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>

On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment tweak

Overall the fix looks good. I made a couple of minor suggestions for the test. Make sure you test on all platforms and with -Xcomp since the test is timing sensitive.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 57:

> 55:         Thread controlThread = new Thread(() -> control(testThread), "Control Thread");
> 56: 
> 57:         setFramePopNotificationMode(testThread, true);

I think we can get rid of this API and just have the native code default to enabling FRAME_POP events. This was copied from a test that would turn it on and off, but this test always needs it on.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 156:

> 154: 
> 155:   // We only want to do a NotifyFramePop once for the main method. The sole purpose is
> 156:   // to force the thread into interpOnly mode, which seems to help the tests's timing

Suggestion:

  // to force the thread into interpOnly mode, which seems to help the test's timing

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2370623582
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1801978159
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1801969813

From never at openjdk.org  Tue Oct 15 21:12:09 2024
From: never at openjdk.org (Tom Rodriguez)
Date: Tue, 15 Oct 2024 21:12:09 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver
In-Reply-To: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
Message-ID: <2GU82lxQpCxOHOba2gWcSYpriAXiIjq8g_kISFatO8w=.d1ebdcc2-daed-479d-b458-0da08cbc3380@github.com>

On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1

The -Xmx1g is probably just copied from ClhsdbPrintAll.java so it could probably be dropped.  Since the point of this test is to exercise nmethod debug info decoding we want LingeredApp to run with Xcomp so that the inspected process has nmethods.  It doesn't matter if anything else is run with Xcomp so whatever accomplishes that seems fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/21519#issuecomment-2415171345

From amenkov at openjdk.org  Tue Oct 15 21:24:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 21:24:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:

> 690:   if (jt->is_in_VTMS_transition()) {
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 692:   } else if (is_virtual) { // filter out pure continuations

Not sure I follow the logic here.
As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
Exception is a call from `get_vthread_jvf()` when vthread is mounted.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 703:

> 701:   if (java_lang_VirtualThread::is_instance(vthread)) { // paranoid check for safety
> 702:     if (java_lang_Thread::is_in_VTMS_transition(vthread)) {
> 703:       jvf = check_and_skip_hidden_frames(java_lang_Thread::is_in_VTMS_transition(vthread), jvf);

it's just checked that `java_lang_Thread::is_in_VTMS_transition(vthread)` is true
Suggestion:

      jvf = check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 2025:

> 2023:   // - it is a good invariant when a thread's handshake can't be impacted by a VTMS transition
> 2024:   // - there is no mechanism to disable transitions of a specific carrier thread yet
> 2025:   JvmtiVTMSTransitionDisabler disabler(is_virtual ? target : nullptr); // nullptr is to disable all

We have a number of places with the same issue - `JvmtiVTMSTransitionDisabler disabler(target)` when target thread can be virtual or platform.
I think they need to be fixed all together (and most likely as a separate issue).
Maybe it would be better to fix disabler itself (check if the thread provided is platform and disable transitions for all threads in the case). Then there is no need to update all this places when (if) disabling for single platform thread is implemented

src/hotspot/share/prims/jvmtiExport.cpp line 1814:

> 1812:   }
> 1813:   // pure continuations have no VTMS transitions but they use methods annotated with JvmtiMountTransition
> 1814:   if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {

Could you please explain the change (and other similar changes in jvmtiExport.cpp)
Before events were not posted for any `@JvmtiMountTransition` methods, and now only for virtual threads? I.e. events for `@JvmtiMountTransition` methods of carrier threads are posted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801933054
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801953309
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1801992736
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802034030

From amenkov at openjdk.org  Tue Oct 15 21:31:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 21:31:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/hotspot/share/prims/jvmtiEnvBase.cpp line 588:

> 586:   // There should not be any VTMS transition here. This is for safety.
> 587:   if (java_thread->is_in_VTMS_transition()) {
> 588:     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(java_thread, jvf);

The code now checks `java_thread->is_in_VTMS_transition()`, so it may be simplified to
Suggestion:

    jvf = JvmtiEnvBase::check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:

> 689: 
> 690:   if (jt->is_in_VTMS_transition()) {
> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);

Suggestion:

    jvf = check_and_skip_hidden_frames(true, jvf);

src/hotspot/share/prims/jvmtiEnvBase.cpp line 753:

> 751:     // Skip hidden frames only for carrier threads
> 752:     // which are in non-temporary VTMS transition.
> 753:     jvf = check_and_skip_hidden_frames(jt, jvf);

Can be
Suggestion:

    jvf = check_and_skip_hidden_frames(true, jvf);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802038615
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802039013
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802039786

From sspitsyn at openjdk.org  Tue Oct 15 21:34:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 21:34:10 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
Message-ID: <V19Qmex4jNy1-pyqxxPczMiPUYoWMl7Owv1rvtUENyo=.d56d80a1-e5d3-4f31-ba50-db76f00401c4@github.com>

On Tue, 15 Oct 2024 20:49:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 156:
> 
>> 154: 
>> 155:   // We only want to do a NotifyFramePop once for the main method. The sole purpose is
>> 156:   // to force the thread into interpOnly mode, which seems to help the tests's timing
> 
> Suggestion:
> 
>   // to force the thread into interpOnly mode, which seems to help the test's timing

Thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802043134

From prr at openjdk.org  Tue Oct 15 21:39:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 15 Oct 2024 21:39:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

I have looked at the source code changes in java.desktop
They are mostly OK.
I have noted text that was removed in two places in java.awt.Robot where the removal should be reverted.
I have also "grepped" the sandbox repo to identify any errors of omission - pertaining to the SE API specification, not internals - and found none.

I also noted a couple of Permission classes we should deprecate - and filed bugs on them.

I have not yet examined any of the test updates. That looks like a big job.

src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:

> 37:  * @apiNote
> 38:  * This permission cannot be used for controlling access to resources anymore
> 39:  * as the Security Manager is no longer supported.

After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

src/java.desktop/share/classes/java/awt/Robot.java line 433:

> 431:      * then a {@code SecurityException} may be thrown,
> 432:      * or the content of the returned {@code Color} is undefined.
> 433:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/java/awt/Robot.java line 460:

> 458:      * then a {@code SecurityException} may be thrown,
> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
> 460:      * </p>

This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java line 36:

> 34:  * actions list; you either have the named permission or you don't.
> 35:  * <p>
> 36:  * The target name is the name of the audio permission.

AudioPermission is another class we should deprecate

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2370309133
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1801765010
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031119
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802031524
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802042388

From sspitsyn at openjdk.org  Tue Oct 15 21:48:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 21:48:10 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
Message-ID: <4-iAWYiOUcdSMFVFWvAq0DMtJdq3eqQVpv8jHPuU-gE=.a3ff03e1-fbe8-4a6b-a57e-a902d8488bca@github.com>

On Tue, 15 Oct 2024 20:51:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 57:
> 
>> 55:         Thread controlThread = new Thread(() -> control(testThread), "Control Thread");
>> 56: 
>> 57:         setFramePopNotificationMode(testThread, true);
> 
> I think we can get rid of this API and just have the native code default to enabling FRAME_POP events. This was copied from a test that would turn it on and off, but this test always needs it on.

Thank you for the suggestion.
I've removed the second parameter and defaulted it to `true`.
The API is still useful as it points to the tested thread the FramePop events have to be enabled for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802055012

From sspitsyn at openjdk.org  Tue Oct 15 21:51:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 21:51:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <KaZBUUtqWTjaGcvFnXyEuJO85tCBvV8DSLh7URWia-M=.98488481-7bf7-41fd-80f1-5ca91cbb092d@github.com>

On Tue, 15 Oct 2024 20:45:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 703:
> 
>> 701:   if (java_lang_VirtualThread::is_instance(vthread)) { // paranoid check for safety
>> 702:     if (java_lang_Thread::is_in_VTMS_transition(vthread)) {
>> 703:       jvf = check_and_skip_hidden_frames(java_lang_Thread::is_in_VTMS_transition(vthread), jvf);
> 
> it's just checked that `java_lang_Thread::is_in_VTMS_transition(vthread)` is true
> Suggestion:
> 
>       jvf = check_and_skip_hidden_frames(true, jvf);

Good catch, thanks. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802057401

From sspitsyn at openjdk.org  Tue Oct 15 22:02:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 22:02:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>

On Tue, 15 Oct 2024 20:40:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
> 
>> 690:   if (jt->is_in_VTMS_transition()) {
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
>> 692:   } else if (is_virtual) { // filter out pure continuations
> 
> Not sure I follow the logic here.
> As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
> Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
> Exception is a call from `get_vthread_jvf()` when vthread is mounted.

This seems to be a good catch. The call to `skip_top_jvmti_annotated_frames()` should not be needed.
It does not harm either, so I've added it for safety.
Will remove it and rerun mach5 tiers to make sure there is nothing unexpected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802065755

From mullan at openjdk.org  Tue Oct 15 22:12:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:12:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>

On Tue, 15 Oct 2024 13:51:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
> 
>> 665:      * @param codesource the codesource
>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>> 667:      * @return the permissions for the codesource
> 
> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?

Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802073264

From sspitsyn at openjdk.org  Tue Oct 15 22:13:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 22:13:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <lvHsBr-2GC7hWJgD3YnI5ItnFb0B6uBoPTiUuzefdPU=.258d189f-fe73-4150-874e-2bc2f026b530@github.com>

On Tue, 15 Oct 2024 20:55:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2025:
> 
>> 2023:   // - it is a good invariant when a thread's handshake can't be impacted by a VTMS transition
>> 2024:   // - there is no mechanism to disable transitions of a specific carrier thread yet
>> 2025:   JvmtiVTMSTransitionDisabler disabler(is_virtual ? target : nullptr); // nullptr is to disable all
> 
> We have a number of places with the same issue - `JvmtiVTMSTransitionDisabler disabler(target)` when target thread can be virtual or platform.
> I think they need to be fixed all together (and most likely as a separate issue).
> Maybe it would be better to fix disabler itself (check if the thread provided is platform and disable transitions for all threads in the case). Then there is no need to update all this places when (if) disabling for single platform thread is implemented

Good suggestion, thanks.
Though, I'd prefer to fix it here, so will prepare a fix in the `JvmtiVTMSTransitionDisabler` constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802073959

From mullan at openjdk.org  Tue Oct 15 22:19:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
Message-ID: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>

On Tue, 15 Oct 2024 19:11:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
> 
>> 70:     private static class StackWalkerHolder {
>> 71:         static final StackWalker STACK_WALKER =
>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
> 
> Suggestion:
> 
>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
> 
> 
> Method info is not needed.

Thanks, will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077370

From mullan at openjdk.org  Tue Oct 15 22:19:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>

On Tue, 15 Oct 2024 21:17:37 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/Robot.java line 433:
> 
>> 431:      * then a {@code SecurityException} may be thrown,
>> 432:      * or the content of the returned {@code Color} is undefined.
>> 433:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

> src/java.desktop/share/classes/java/awt/Robot.java line 460:
> 
>> 458:      * then a {@code SecurityException} may be thrown,
>> 459:      * or the contents of the returned {@code BufferedImage} are undefined.
>> 460:      * </p>
> 
> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.

Ok, I will revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802077916
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802078111

From mullan at openjdk.org  Tue Oct 15 22:19:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 15 Oct 2024 22:19:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>

On Tue, 15 Oct 2024 15:01:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
> 
>> 223:      *
>> 224:      * @exception SecurityException if the connection cannot be made
>> 225:      * for security reasons.
> 
> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.

Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802076052

From cjplummer at openjdk.org  Tue Oct 15 22:26:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 15 Oct 2024 22:26:10 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
Message-ID: <M3tJ-Y5CLkAdpP18Z_duhRS1rNQGJHftQv8BsdkkpQ0=.a33cd64c-6fee-4bf3-a98c-6ff4158e8167@github.com>

On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment tweak

src/hotspot/share/prims/jvmtiThreadState.hpp line 364:

> 362:   void set_top_frame_is_exiting() { _top_frame_is_exiting = true;  }
> 363:   void clr_top_frame_is_exiting() { _top_frame_is_exiting = false; }
> 364:   bool is_top_frame_is_exiting()  { return _top_frame_is_exiting;  }

Just noticed you are using "is" twice in this API. I'm not sure of the hotspot convention here. Seems probably the first "is" should be dropped.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802083174

From amenkov at openjdk.org  Tue Oct 15 22:31:46 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 22:31:46 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:

 - updated comment
 - feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20782/files
  - new: https://git.openjdk.org/jdk/pull/20782/files/1fed4ea6..86bd1cd2

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

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

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

From amenkov at openjdk.org  Tue Oct 15 22:31:46 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 15 Oct 2024 22:31:46 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v3]
In-Reply-To: <7nf9YVsVg_UA_kD85dcBd8tT0_J_maZ5H-WGBEgWdbU=.685a1387-c66e-4514-8c74-1da1bf4bac57@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <wEMIEFXTDgPr6HVPsm2sS9il-lRJ_R_Mfsxxrs3_-gE=.8bf17468-6e5d-4a98-b5bd-1a3fa1319503@github.com>
 <7nf9YVsVg_UA_kD85dcBd8tT0_J_maZ5H-WGBEgWdbU=.685a1387-c66e-4514-8c74-1da1bf4bac57@github.com>
Message-ID: <bLwjeziLvI_jv0lEfjS-zsNzmATsyKWEXdQp45dqJ84=.048596ac-18b7-47eb-85c8-99f9653b01f4@github.com>

On Tue, 15 Oct 2024 09:52:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed JVM_EnqueueOperation2
>>   
>>   renamed JVM_EnqueueOperation2 to JVM_EnqueueOperation_v2 for consistency (per Serguei request)
>
> src/hotspot/os/windows/attachListener_windows.cpp line 40:
> 
>> 38: // executes a small stub generated by the client. The stub invokes the
>> 39: // JVM_EnqueueOperation or JVM_EnqueueOperation_v2 function which checks the operation parameters
>> 40: // and enqueues the operation request to the queue serviced by the attach listener. The thread created by
> 
> Nit: Just a suggestion to simplify this line of comment a little bit:
>   // and enqueues the operation request for the attach listener. The thread created by

I've made it "enqueues the operation request to the queue."

> src/hotspot/os/windows/attachListener_windows.cpp line 108:
> 
>> 106:                             size,
>> 107:                             &nread,
>> 108:                             nullptr);   // not overlapped
> 
> Nit: Missed space after `fsuccess` at line 104.
>        Also, there is not cast `(DWORD)size` at line 106 as it is done in the `WriteFile()` call at line 118.

Fixed both indent and cast

> src/hotspot/os/windows/attachListener_windows.cpp line 194:
> 
>> 192:   }
>> 193:   const char* arg(int i) const {
>> 194:     return (i >= 0 && AttachOperation::arg_count_max) ? _arg[i] : nullptr;
> 
> Nit: Dot is not needed at the end of comment at line 140.
> Q: Should the condition at line 194 be modified as below:
>    ```return (i >= 0 && i < AttachOperation::arg_count_max) ? _arg[i] : nullptr;```

Good catch! Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1802084434
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1802084837
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1802086150

From dholmes at openjdk.org  Tue Oct 15 22:44:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 15 Oct 2024 22:44:17 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v15]
In-Reply-To: <1ZXms0ZIxS7YIAqTp97N51dVk8iNpwuBm_zLPO6qqYw=.18911399-dfb8-4293-bba4-57e643561065@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
 <1ZXms0ZIxS7YIAqTp97N51dVk8iNpwuBm_zLPO6qqYw=.18911399-dfb8-4293-bba4-57e643561065@github.com>
Message-ID: <modBDtvciIVMJELn8_8smg7yFTVmJoSucLFVe2Fy_3w=.bd036771-d078-498a-8db7-2c8df6bfca9d@github.com>

On Mon, 14 Oct 2024 07:19:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> **Overview**
>> 
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
>> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
>> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
>> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
>> 
>> **All-or-nothing Loading**
>> 
>> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
>> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
>> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exa...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one file from last commit

Still good for me - but seems to be jcheck whitespace issues.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20843#pullrequestreview-2370819827

From duke at openjdk.org  Tue Oct 15 22:44:35 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Tue, 15 Oct 2024 22:44:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v42]
In-Reply-To: <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
Message-ID: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>

On Tue, 15 Oct 2024 10:47:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix aarch64.ad

Finished reviewing `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp`, line by line and comparing old snippets that got merged into the new function: looks good to me, every (new) case handled 

Only have some minor comments about comments.

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 414:

> 412:   // to the valid haystack bytes on the stack.
> 413:   {
> 414:     const Register haystack = rbx;

Keep `rax` as index for clarity? Although it is really used as a temp..


const Register index = rax;
const Register haystack = rbx;
copy_to_stack(haystack, haystack_len, false, index , XMM_TMP1, _masm);

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1568:

> 1566:   assert((COPIED_HAYSTACK_STACK_SIZE == 64), "Must be 64!");
> 1567: 
> 1568:   // Copy incoming haystack onto stack

Old comment was slightly more precise. Move here. i.e.
`// Copy incoming haystack onto stack (haystack <= 32 bytes)`

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1634:

> 1632: 
> 1633: 
> 1634: // Copy the small (< 32 byte) haystack to the stack.  Allows for vector reads without page fault

Just to be pedantic, its `(<=32)` - this function also handles 32bytes case.

-  line 401: 

 __ cmpq(haystack_len, 0x20);
 __ ja(L_bigSwitchTop);

- though line 293 (`highly_optimized_short_cases`) only seems to route16-byte cases here: 
```__ cmpq(haystack_len_p, isU ? 8 : 16);```

src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1659:

> 1657:   Label L_moreThan8, L_moreThan16, L_moreThan24, L_adjustHaystack;
> 1658: 
> 1659:   assert(arrayOopDesc::base_offset_in_bytes(isU ? T_CHAR : T_BYTE) >= 8,

If we had to also optimize for header-size 16, it might be possible to remove one jump here. Looks correct for either size.

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2370735887
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802041876
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802044880
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802088545
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802073195

From lmesnik at openjdk.org  Tue Oct 15 23:01:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 15 Oct 2024 23:01:14 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver
In-Reply-To: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
Message-ID: <PsS2VT2p0PxabnTg-R3X2TJvTtRwHES4xNgxQmfDjMk=.9365effd-6212-4bd9-98bd-b5b91faad17b@github.com>

On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1

The only thing that is missed it change `othervm` to `driver`.

The adding -Xcomp in LingeredApp.startApp(theApp, "-Xmx1g", "-Xcomp");
should works fine except when -Xint/-Xmixed is set explicitly. 
So  generally test like needs to have 
@requires  vm.compMode == "null" | vm.compMode == "Xcomp"
 However we don't set these modes, so it might be skipped. A lot of our test set Xcomp without any requires now.
Also, the vm.flagless is not required, since test support various vm flags.
Limiting tests to run only -Xcomp is set is also not needed for this test. 

The another thing to check (unrelated to the fix) is if test is executed in tier1 and should it be there.

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

PR Comment: https://git.openjdk.org/jdk/pull/21519#issuecomment-2415309978

From wkemper at openjdk.org  Tue Oct 15 23:03:21 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Oct 2024 23:03:21 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <_1_RPbV4VVoczxDhQYp967iOM37EHh3ZcK5b8dvKrQU=.1b9556a6-81d3-428d-8593-bd4cdced44de@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <_1_RPbV4VVoczxDhQYp967iOM37EHh3ZcK5b8dvKrQU=.1b9556a6-81d3-428d-8593-bd4cdced44de@github.com>
Message-ID: <1FBHl-vUAvyx5tv2VG7jM86Lx5DM1aaIgE9-jTNv-9s=.b68703f8-f9bf-4952-9e1f-9da7a68bb7de@github.com>

On Fri, 11 Oct 2024 13:43:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java line 100:
> 
>> 98: 
>> 99: /*
>> 100:  * @test id=generational
> 
> You are making a test configuration and call it 'generational' but then one of the two run configurations doesn't actually run with generational mode. You probably want to separate the two?

https://bugs.openjdk.org/browse/JDK-8342278

> test/hotspot/jtreg/gc/shenandoah/TestAllocIntArrays.java line 163:
> 
>> 161:         final int min = 0;
>> 162:         final int max = 384 * 1024;
>> 163:         // Each allocated int array is assumed to consume 16 bytes for alignment and header, plus
> 
> With the upcoming 'compact headers' it's going to be only 12 bytes. If that matters, then the actual number should perhaps be a constant? Preexisting and not relevant for this PR, though.

Yes, not sure that level of precision is really required for this test either.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1802109516
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1802109841

From iklam at openjdk.org  Tue Oct 15 23:40:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 23:40:41 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v15]
In-Reply-To: <modBDtvciIVMJELn8_8smg7yFTVmJoSucLFVe2Fy_3w=.bd036771-d078-498a-8db7-2c8df6bfca9d@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
 <1ZXms0ZIxS7YIAqTp97N51dVk8iNpwuBm_zLPO6qqYw=.18911399-dfb8-4293-bba4-57e643561065@github.com>
 <modBDtvciIVMJELn8_8smg7yFTVmJoSucLFVe2Fy_3w=.bd036771-d078-498a-8db7-2c8df6bfca9d@github.com>
Message-ID: <ptrbIvQGHRJ3OcuUgnEzMPXqIk3GP73XeHfOiuCMKCA=.17469dda-ea7c-421b-9733-ef605afa9f21@github.com>

On Tue, 15 Oct 2024 22:41:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Still good for me - but seems to be jcheck whitespace issues.

Thanks for noticing it. I've fixed the whitespaces (and need to propagate that to all subsequent PRs in this series).

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

PR Comment: https://git.openjdk.org/jdk/pull/20843#issuecomment-2415345421

From iklam at openjdk.org  Tue Oct 15 23:40:41 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 15 Oct 2024 23:40:41 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v16]
In-Reply-To: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
Message-ID: <EK2Qn4cImSY9TC1xCbz-0xWIgptzvDsf5MqKbSoGBds=.e5c9ab8f-7abf-4c46-8e2b-ecf1b0953bd7@github.com>

> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Overview**
> 
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
> 
> **All-or-nothing Loading**
> 
> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exact same set of modules are visible whe...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20843/files
  - new: https://git.openjdk.org/jdk/pull/20843/files/22c47d33..6bb38cb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=14-15

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

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

From sspitsyn at openjdk.org  Tue Oct 15 23:57:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 15 Oct 2024 23:57:12 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <Coxxx27XK_o-016soDPO56loNY-zTu4KSEtSH0gCSpw=.089768fa-ccc5-42a3-93ca-56cc52d678ce@github.com>
Message-ID: <81rOWotluAxLNE9hrmhLmPRVmdeieCH8XfkbCRF3iMc=.8ea9d4b6-4678-42a9-914d-96b4e366e195@github.com>

On Tue, 15 Oct 2024 20:54:45 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Overall the fix looks good. I made a couple of minor suggestions for the test. Make sure you test on all platforms and with -Xcomp since the test is timing sensitive.

Thank you for reviewing this! Good suggestion about an extensive testing with -Xcomp.

> src/hotspot/share/prims/jvmtiThreadState.hpp line 364:
> 
>> 362:   void set_top_frame_is_exiting() { _top_frame_is_exiting = true;  }
>> 363:   void clr_top_frame_is_exiting() { _top_frame_is_exiting = false; }
>> 364:   bool is_top_frame_is_exiting()  { return _top_frame_is_exiting;  }
> 
> Just noticed you are using "is" twice in this API. I'm not sure of the hotspot convention here. Seems probably the first "is" should be dropped.

Good catch, thanks. Fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21468#issuecomment-2415360803
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802139368

From dholmes at openjdk.org  Wed Oct 16 00:06:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 00:06:15 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
Message-ID: <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>

On Sun, 13 Oct 2024 15:38:49 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
>> 
>> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
>> 
>> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
>> 
>> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up test code

Hi @stooke , I was away on vacation when you made the updates.

I'm afraid I still have some issues about expected behaviour on Windows with regard to the tests.

test/hotspot/gtest/runtime/test_os.cpp line 413:

> 411: 
> 412: TEST_VM(os, realpath) {
> 413:   /* POSIX requires that the file exists, Windows doesn't */

I'm not sure what this comment means. I can't fully discern from

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fullpath-wfullpath?view=msvc-170

what Windows does if the path does not exist.

test/hotspot/gtest/runtime/test_os.cpp line 422:

> 420:   errno = 0;
> 421:   const char* returnedBuffer = os::realpath(nosuchpath, buffer, sizeof(nosuchpath) - 2);
> 422:   /* Returns ENOENT on Linux, ENAMETOOLONG on Windows */

Suggestion:

  /* Reports ENOENT on Linux, ENAMETOOLONG on Windows */

and similarly below.

test/hotspot/gtest/runtime/test_os.cpp line 425:

> 423:   EXPECT_TRUE(returnedBuffer == nullptr);
> 424: #if defined(_WINDOWS)
> 425:   EXPECT_TRUE(errno == ENAMETOOLONG);

Why is this the case? Our implementation does not set it and `_fullpath` makes no mention of it.

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

PR Review: https://git.openjdk.org/jdk/pull/20683#pullrequestreview-2370878680
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1802144245
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1802139054
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1802142390

From sspitsyn at openjdk.org  Wed Oct 16 00:07:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 00:07:11 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
Message-ID: <ZtOp7cI2LTZss_zZlSBy9ZYYZSRlIv9H-PreTbNiFI8=.9a14ee60-b05f-4370-86c8-699cdabacaee@github.com>

On Tue, 15 Oct 2024 22:31:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated comment
>  - feedback

Thank you for the updates. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20782#pullrequestreview-2370886982

From amenkov at openjdk.org  Wed Oct 16 00:10:17 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Oct 2024 00:10:17 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
Message-ID: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>

On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment tweak

The fix looks good.
Added notes about the test

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 103:

> 101:                 }
> 102:             }
> 103:             if (waitCount > 50) {

Is 50 is enough here? (like in "Xcomp" mode) the cycle above exits after 1000 iterations.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 109:

> 107:             }
> 108:         }
> 109:         System.out.println("control has finished: " + notifyCount);

Could you please update logging to use `log` or `System.out.println` in all cases?

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 43:

> 41: #endif
> 42: 
> 43: #endif

This is copy of some old .c code. you don't need it in .cpp

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 45:

> 43: #endif
> 44: 
> 45: static jvmtiEnv *jvmti = NULL;

NULL -> nullptr

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 49:

> 47: static jvmtiEventCallbacks callbacks;
> 48: static volatile jint popCount = 0;
> 49: static char* lastNotifyMethod;

it's accessed from different threads. should be volative at least (but better would be be use atomic). The same for `popCount` and `failed`

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 76:

> 74:   jclass cls = NULL;
> 75:   char* csig = NULL;
> 76:   char* name = NULL;

NULL -> nullptr

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 83:

> 81:   check_jvmti_status(jni, err, "FramePop: Failed in JVMTI GetMethodDeclaringClass");
> 82: 
> 83:   err =jvmti->GetClassSignature(cls, &csig, NULL);

NULL -> nullptr

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 93:

> 91:       LOG("ERROR: FramePop event is for wrong method: expected %s, got %s\n", lastNotifyMethod, name);
> 92:       failed = JNI_TRUE;
> 93:       fatal(jni, "DBG: FramePop event in wrong method\n");

looks like "DBG" is leftover from other test?

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 161:

> 159:   if (isMain) {
> 160:     if (seenMain) {
> 161:       return JNI_FALSE; // Only do NotifyFramePop once for main()

`deallocate(jvmti, jni, name);`

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 169:

> 167:   err= jvmti->NotifyFramePop(thread, 0);
> 168:   if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERROR_DUPLICATE) {
> 169:     return JNI_FALSE;

`deallocate(jvmti, jni, name);`

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

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2370871906
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802134354
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802134738
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802135343
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802136401
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802138245
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802138433
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802138857
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802140636
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802144857
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802145015

From amenkov at openjdk.org  Wed Oct 16 00:40:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Oct 2024 00:40:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
Message-ID: <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>

On Fri, 11 Oct 2024 09:26:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment tweak

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @summary Verifies NotifyFramePop request is cleared if JVMTI_EVENT_FRAME_POP is disabled

Summary does not look correct

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 37:

> 35: public class NotifyFramePopStressTest {
> 36:     static volatile boolean done = false;
> 37:     static volatile int notifyCount = 0;

don't need to be volatile (actually it can be local in `control` method)

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 129:

> 127: 
> 128:     private static int foo() {
> 129:         return fetchInt();

The test checks name of the method being popped.
I think it would be better to call different methods from `foo()` and `bar()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157865
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802159018
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802157540

From cjplummer at openjdk.org  Wed Oct 16 00:52:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 16 Oct 2024 00:52:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
Message-ID: <Yl090HZ9QIcYIn3tLPrwEIHcC8QnkYJHZ08FC1RUEX8=.0de9eee2-143e-4fb1-8381-58526b800f6b@github.com>

On Tue, 15 Oct 2024 23:43:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 103:
> 
>> 101:                 }
>> 102:             }
>> 103:             if (waitCount > 50) {
> 
> Is 50 is enough here? (like in "Xcomp" mode) the cycle above exits after 1000 iterations.

It was written to fail if the count is over 50, but it will wait up to 1000 before exiting the loop to provide a bit of debugging info. If it gets to a 1000, then the test is probably stuck. If it fail let's say at 75, then maybe the test just needs an adjustment to wait for more iterations.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 169:
> 
>> 167:   err= jvmti->NotifyFramePop(thread, 0);
>> 168:   if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERROR_DUPLICATE) {
>> 169:     return JNI_FALSE;
> 
> `deallocate(jvmti, jni, name);`

Also add a LOG similar to the one below that is done if successful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802168851
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802166576

From sspitsyn at openjdk.org  Wed Oct 16 01:10:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:10:55 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v3]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <9g1Q-1dxGmdV6ixxkKWsezGmK6faRcMyftc1QZfPCuc=.db46f285-48ea-4dd0-b6bc-e315bdcc90d6@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review: addressed comments from Chris: test tweaks, minor function name correction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/c68625be..e4e54f9e

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

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

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

From sspitsyn at openjdk.org  Wed Oct 16 01:16:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:16:23 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
Message-ID: <lak4sFnpdJmzfwryWT8Fo81MeFOabQ1Kp-WWdvSiz8U=.d2d064df-0fcf-480c-86bf-2ea051ebe45d@github.com>

On Tue, 15 Oct 2024 23:44:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 109:
> 
>> 107:             }
>> 108:         }
>> 109:         System.out.println("control has finished: " + notifyCount);
> 
> Could you please update logging to use `log` or `System.out.println` in all cases?

Good suggestion. Changed to use `log()` in all cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802196907

From duke at openjdk.org  Wed Oct 16 01:18:23 2024
From: duke at openjdk.org (duke)
Date: Wed, 16 Oct 2024 01:18:23 GMT
Subject: Withdrawn: 8337517: Redacted Heap Dumps
In-Reply-To: <lUXbFiJNR5VxlP7Z_yDSPjjOo-SCs3pgNBItsnbDk1U=.4a6ac697-956d-4f6c-af3f-3b61e53c5716@github.com>
References: <lUXbFiJNR5VxlP7Z_yDSPjjOo-SCs3pgNBItsnbDk1U=.4a6ac697-956d-4f6c-af3f-3b61e53c5716@github.com>
Message-ID: <LByBd1cPm88t3jA4JPVjx_tIe6cfbpD8re6sJaNr-ps=.fd3feb7a-3f8d-49ba-b98f-75d12a2ab31b@github.com>

On Wed, 31 Jul 2024 19:10:41 GMT, Henry Lin <duke at openjdk.org> wrote:

> Adds a command line option `-redact` to `jcmd` and `-XX:+HeapDumpRedacted` enabling redacted heap dumps. When enabled, the output binary heap dump has zeroes written out in place of the original primitive values in the object fields. There is a new jtreg test `heapDumpRedactedTest.java` that tests that the fields are properly redacted.

This pull request has been closed without being integrated.

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

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

From sspitsyn at openjdk.org  Wed Oct 16 01:27:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:27:19 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
Message-ID: <da9EtZbus4HPZF0xCFfLg6IrHFzdwV9IsCNkXBi_glo=.870bb107-83c0-4be1-8dca-798fc00fe2bf@github.com>

On Tue, 15 Oct 2024 23:45:15 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 43:
> 
>> 41: #endif
>> 42: 
>> 43: #endif
> 
> This is copy of some old .c code. you don't need it in .cpp

Thanks, removed obsolete code.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 45:
> 
>> 43: #endif
>> 44: 
>> 45: static jvmtiEnv *jvmti = NULL;
> 
> NULL -> nullptr

Thanks. Fixed all occurrences.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 76:
> 
>> 74:   jclass cls = NULL;
>> 75:   char* csig = NULL;
>> 76:   char* name = NULL;
> 
> NULL -> nullptr

Fixed.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 83:
> 
>> 81:   check_jvmti_status(jni, err, "FramePop: Failed in JVMTI GetMethodDeclaringClass");
>> 82: 
>> 83:   err =jvmti->GetClassSignature(cls, &csig, NULL);
> 
> NULL -> nullptr

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802204640
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802206054
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802206722
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802206932

From sspitsyn at openjdk.org  Wed Oct 16 01:40:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:40:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
Message-ID: <gPDgeKRJ67Pign8V2WOg0diUABMcG6RVoilpMhn4sw4=.6f0dc129-68f0-474f-a306-6f56e6e7d284@github.com>

On Tue, 15 Oct 2024 23:55: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:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 93:
> 
>> 91:       LOG("ERROR: FramePop event is for wrong method: expected %s, got %s\n", lastNotifyMethod, name);
>> 92:       failed = JNI_TRUE;
>> 93:       fatal(jni, "DBG: FramePop event in wrong method\n");
> 
> looks like "DBG" is leftover from other test?

Thanks. Removed "DBG: " prefix.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 161:
> 
>> 159:   if (isMain) {
>> 160:     if (seenMain) {
>> 161:       return JNI_FALSE; // Only do NotifyFramePop once for main()
> 
> `deallocate(jvmti, jni, name);`

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802213563
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802214841

From sspitsyn at openjdk.org  Wed Oct 16 01:49:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:49:10 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <Yl090HZ9QIcYIn3tLPrwEIHcC8QnkYJHZ08FC1RUEX8=.0de9eee2-143e-4fb1-8381-58526b800f6b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
 <Yl090HZ9QIcYIn3tLPrwEIHcC8QnkYJHZ08FC1RUEX8=.0de9eee2-143e-4fb1-8381-58526b800f6b@github.com>
Message-ID: <dbKaBnUkj5p3ixiwAQM3DYWpm0ky0wACDlCrJjVTxoE=.59d30d75-9a46-480f-991b-9a57c215147d@github.com>

On Wed, 16 Oct 2024 00:45:17 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 169:
>> 
>>> 167:   err= jvmti->NotifyFramePop(thread, 0);
>>> 168:   if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERROR_DUPLICATE) {
>>> 169:     return JNI_FALSE;
>> 
>> `deallocate(jvmti, jni, name);`
>
> Also add a LOG similar to the one below that is done if successful.

Thanks. Added lines as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802219985

From sspitsyn at openjdk.org  Wed Oct 16 01:53:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:53:14 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
Message-ID: <hDuUBwRxG32sways0KnmSRzBVdna5mMj63woNjH4-L8=.b8bba7c5-95cc-44c4-9177-684fa28a87da@github.com>

On Wed, 16 Oct 2024 00:28:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @summary Verifies NotifyFramePop request is cleared if JVMTI_EVENT_FRAME_POP is disabled
> 
> Summary does not look correct

Updated the summary, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802222317

From sspitsyn at openjdk.org  Wed Oct 16 01:59:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 01:59:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
Message-ID: <JvA2scxVzmiOTY7rUPLqH-jQxrHqUY60uLhlbTWXlZw=.fd71343e-9655-410d-9d11-8830040e9aad@github.com>

On Wed, 16 Oct 2024 00:28:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 129:
> 
>> 127: 
>> 128:     private static int foo() {
>> 129:         return fetchInt();
> 
> The test checks name of the method being popped.
> I think it would be better to call different methods from `foo()` and `bar()`

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802226080

From sspitsyn at openjdk.org  Wed Oct 16 02:02:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 02:02:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <MUy77nXXzI4YwzCVGHQPjVCKQyHGR4fnkgxSmcrF1ZM=.8434e253-c11f-415c-9d1c-e2f7283a7f90@github.com>
Message-ID: <d54rtSRWmRACsjlwaSqGQ7dA38V2RWMWhlKLVDG5mTM=.fdb37f3e-7066-4557-82e2-f3bba9df608f@github.com>

On Wed, 16 Oct 2024 00:30:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 37:
> 
>> 35: public class NotifyFramePopStressTest {
>> 36:     static volatile boolean done = false;
>> 37:     static volatile int notifyCount = 0;
> 
> don't need to be volatile (actually it can be local in `control` method)

Good suggestion. Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802227945

From sspitsyn at openjdk.org  Wed Oct 16 02:13:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 02:13:11 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
Message-ID: <cKsfDeTM4LmJlyiE2kZQPeKLtv6hjFlPI6eTNSOtE7U=.1a616c66-0e8f-4cc0-be98-8d0387f88d9a@github.com>

On Tue, 15 Oct 2024 23:50:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment tweak
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 49:
> 
>> 47: static jvmtiEventCallbacks callbacks;
>> 48: static volatile jint popCount = 0;
>> 49: static char* lastNotifyMethod;
> 
> it's accessed from different threads. should be volative at least (but better would be be use atomic). The same for `popCount` and `failed`

Thanks. Made volatile:`lastNotifyMethod` and `failed`.
Renamed according to native naming convention:
  `popCount` => `pop_count`, `lastNotifyMethod` => `last_notify_method`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802235396

From sspitsyn at openjdk.org  Wed Oct 16 02:18:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 02:18:10 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v2]
In-Reply-To: <Yl090HZ9QIcYIn3tLPrwEIHcC8QnkYJHZ08FC1RUEX8=.0de9eee2-143e-4fb1-8381-58526b800f6b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <XSeZnPAQlPLLf1Vv7XWAK1GZVoGEsYzr_xO0QQ3-9C0=.85b1e1ce-3186-4e06-a513-2693425d3933@github.com>
 <3d2Sjn0Mylfyee8ldh1NVINlrW5oxEAja8HeEU6YuRU=.73a7e634-5b65-4a52-878c-e98e60502472@github.com>
 <Yl090HZ9QIcYIn3tLPrwEIHcC8QnkYJHZ08FC1RUEX8=.0de9eee2-143e-4fb1-8381-58526b800f6b@github.com>
Message-ID: <Xs9Pd7_unMUIiqSVSQu1ZBhkUKk6rFkuRCk3zUnVWSw=.9d7362b0-5fe6-4338-8b95-fe6c3fcabfb6@github.com>

On Wed, 16 Oct 2024 00:49:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 103:
>> 
>>> 101:                 }
>>> 102:             }
>>> 103:             if (waitCount > 50) {
>> 
>> Is 50 is enough here? (like in "Xcomp" mode) the cycle above exits after 1000 iterations.
>
> It was written to fail if the count is over 50, but it will wait up to 1000 before exiting the loop to provide a bit of debugging info. If it gets to a 1000, then the test is probably stuck. If it fail let's say at 75, then maybe the test just needs an adjustment to wait for more iterations.

I've changed it from 50 to 100 but this can be not enough for `-Xcomp`.
I've never seen it yet failed with `-Xcomp` though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1802239003

From sspitsyn at openjdk.org  Wed Oct 16 02:28:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 02:28:28 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review: resolved comments from Alex and Chris

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/e4e54f9e..3b82454f

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

  Stats: 66 lines in 2 files changed: 14 ins; 27 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/21468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21468/head:pull/21468

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

From sspitsyn at openjdk.org  Wed Oct 16 02:28:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 02:28:29 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v3]
In-Reply-To: <9g1Q-1dxGmdV6ixxkKWsezGmK6faRcMyftc1QZfPCuc=.db46f285-48ea-4dd0-b6bc-e315bdcc90d6@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <9g1Q-1dxGmdV6ixxkKWsezGmK6faRcMyftc1QZfPCuc=.db46f285-48ea-4dd0-b6bc-e315bdcc90d6@github.com>
Message-ID: <HFzOdf_CnH77S6tlgDmAwjCYMhVbR6-81RgGsqbQWhI=.78768fd6-2a2c-4ac8-a476-ead126faf5d9@github.com>

On Wed, 16 Oct 2024 01:10:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed comments from Chris: test tweaks, minor function name correction

Chris and Alex, I believe that I've resolved all comments from you.
Please, let me know if anything is still missed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21468#issuecomment-2415594359

From dholmes at openjdk.org  Wed Oct 16 06:23:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 06:23:12 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v3]
In-Reply-To: <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <PWmasPxlAwldjDjFAFm9ApqAVKwmHuy3Q4fpZRv-gCo=.c06468eb-3576-42bd-aa69-e8a8f64583b6@github.com>
Message-ID: <_Lz4FqcQaQ7_HhbNu6zM6tVkxlEW2Jy3-69VdGi7KLo=.d04c2358-54ec-49a3-90ea-4fdf4af3c61a@github.com>

On Fri, 11 Oct 2024 06:43:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas 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 12 additional commits since the last revision:
> 
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - Add missing problem-listing
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/5efb98a4...e58b4c5a

I skimmed everything and it seems okay to me.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2371314286

From alanb at openjdk.org  Wed Oct 16 06:31:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 06:31:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
Message-ID: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>

On Tue, 15 Oct 2024 22:15:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 72:
>> 
>>> 70:     private static class StackWalkerHolder {
>>> 71:         static final StackWalker STACK_WALKER =
>>> 72:             StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 
>> Suggestion:
>> 
>>             StackWalker.getInstance(Set.of(Option.DROP_METHOD_INFO, Option.RETAIN_CLASS_REFERENCE));
>> 
>> 
>> Method info is not needed.
>
> Thanks, will fix.

SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have not in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802437558

From alanb at openjdk.org  Wed Oct 16 07:01:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 07:01:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
Message-ID: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>

On Tue, 15 Oct 2024 22:16:27 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Robot.java line 433:
>> 
>>> 431:      * then a {@code SecurityException} may be thrown,
>>> 432:      * or the content of the returned {@code Color} is undefined.
>>> 433:      * </p>
>> 
>> This text should not have been removed. It pertains to the desktop permissions as well as the Java SecurityManager.
>
> Ok, I will revert it.

The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802471843

From dholmes at openjdk.org  Wed Oct 16 07:08:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 16 Oct 2024 07:08:24 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v16]
In-Reply-To: <EK2Qn4cImSY9TC1xCbz-0xWIgptzvDsf5MqKbSoGBds=.e5c9ab8f-7abf-4c46-8e2b-ecf1b0953bd7@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
 <EK2Qn4cImSY9TC1xCbz-0xWIgptzvDsf5MqKbSoGBds=.e5c9ab8f-7abf-4c46-8e2b-ecf1b0953bd7@github.com>
Message-ID: <8O-DiOv48ck2FlSxcU0B7Q5hYUzbiNy4nzhr0WNKH0s=.9337f1a6-da8c-46d9-abe7-3115d1dba39b@github.com>

On Tue, 15 Oct 2024 23:40:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> **Overview**
>> 
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
>> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
>> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
>> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
>> 
>> **All-or-nothing Loading**
>> 
>> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
>> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
>> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exa...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespaces

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20843#pullrequestreview-2371393445

From alanb at openjdk.org  Wed Oct 16 08:03:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:03:17 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/java.base/share/classes/java/lang/VirtualThread.java line 221:

> 219:                     vthread.notifyJvmtiStart();
> 220: 
> 221:                     vthread.run(task);

This doesn't look right, it needs to use try-finally.

src/java.base/share/classes/java/lang/VirtualThread.java line 423:

> 421:                 }
> 422: 
> 423:             } finally {

This means an empty finally block, I assume you'll remove the try-finally here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802558723
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802559933

From alanb at openjdk.org  Wed Oct 16 08:08:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:08:16 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
Message-ID: <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>

On Wed, 9 Oct 2024 22:58:33 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run

src/java.base/share/classes/java/lang/VirtualThread.java line 219:

> 217:                 public void run() {
> 218:                     // notify JVMTI
> 219:                     vthread.notifyJvmtiStart();

The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802569291

From alanb at openjdk.org  Wed Oct 16 08:37:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 08:37:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
Message-ID: <eDT17ezlw65yxabhUuwqn337hsf_yb9aZyjc7Cs2TTw=.60e28c95-d6e4-4d23-a9b6-bc0b1e0cdd55@github.com>

On Tue, 15 Oct 2024 18:57:11 GMT, Phil Race <prr at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/java.desktop/share/classes/java/awt/AWTPermission.java line 39:
> 
>> 37:  * @apiNote
>> 38:  * This permission cannot be used for controlling access to resources anymore
>> 39:  * as the Security Manager is no longer supported.
> 
> After this JEP is integrated, I expect to deprecate AWTPermission, probably for removal

JEP 486 lists deprecating the permission classes as future work. It would be very disruptive to do this now, but will be a lot easier once the JEP is integrated and the post-JEP tasks to remove the hundreds of usages in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1802617206

From rkennke at openjdk.org  Wed Oct 16 09:01:34 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:01:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
 <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <9pMfQtqoAkkOP0pYjYrqozV1umS5A-BYo2a0GsNcihA=.7779b1c5-993c-4c60-9b65-31fb3c57e659@github.com>

On Tue, 15 Oct 2024 21:30:13 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 414:
> 
>> 412:   // to the valid haystack bytes on the stack.
>> 413:   {
>> 414:     const Register haystack = rbx;
> 
> Keep `rax` as index for clarity? Although it is really used as a temp..
> 
> 
> const Register index = rax;
> const Register haystack = rbx;
> copy_to_stack(haystack, haystack_len, false, index , XMM_TMP1, _masm);

I'll use rax as tmp, then.

const Register tmp = rax;
const Register haystack = rbx;
copy_to_stack(haystack, haystack_len, false, tmp , XMM_TMP1, _masm);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802659159

From rkennke at openjdk.org  Wed Oct 16 09:05:32 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:05:32 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
 <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <vwaTIEUTS7HUI9kyrTATPU4rBNCkfdadecgfLxP6s3k=.f0f5ef80-dd3b-4511-9051-4918ba664f61@github.com>

On Tue, 15 Oct 2024 22:09:54 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1659:
> 
>> 1657:   Label L_moreThan8, L_moreThan16, L_moreThan24, L_adjustHaystack;
>> 1658: 
>> 1659:   assert(arrayOopDesc::base_offset_in_bytes(isU ? T_CHAR : T_BYTE) >= 8,
> 
> If we had to also optimize for header-size 16, it might be possible to remove one jump here. Looks correct for either size.

Yeah. The old code optimized for header-size >= 16. But given that compact headers will soon become the default, I don't think it's worth optimizing for the old header layout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802665723

From kevinw at openjdk.org  Wed Oct 16 09:12:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 16 Oct 2024 09:12:56 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v2]
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <x01CSb6rYEnhPy78xvvd36hqq9QT0Xca1nCPLGz6SPg=.5d9d7d1c-d0f3-49a5-a057-0156fe7ce5af@github.com>

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

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:

 - Update JFR commands for FILE
 - Merge remote-tracking branch 'upstream/master' into 8337276_jcmd_pid_manpage
 - 8337276: jcmd man page update for PID in output filenames

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20401/files
  - new: https://git.openjdk.org/jdk/pull/20401/files/c971843d..7d077a79

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

  Stats: 290428 lines in 3285 files changed: 242467 ins; 29684 del; 18277 mod
  Patch: https://git.openjdk.org/jdk/pull/20401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20401/head:pull/20401

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

From kevinw at openjdk.org  Wed Oct 16 09:12:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 16 Oct 2024 09:12:56 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <7XUe1-il-asTCSx7afurftue8oYjbc2Ug-UGFUlLpHM=.c04dc8ad-64be-45a8-af40-5084652813ef@github.com>

On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

Updating.
Since JDK-8338405, JFR.dump, JFR.start, JFR.stop also now use FILE.

JFR items already mention %t and %p, but we don't really want the man page and the live jcmd help giving diffrent information, so say "FILE" in the man page.

(We may come back here again for JDK-8204681 if we add a more general timetamp in output filename feature.)

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

PR Comment: https://git.openjdk.org/jdk/pull/20401#issuecomment-2416191111

From rkennke at openjdk.org  Wed Oct 16 09:16:36 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:16:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v42]
In-Reply-To: <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <5x48SX55xY_BRxqqcTTvGp_ocrKDH7t5VuJY-MDQuTA=.eed6083d-e2dc-4888-a2d5-b6934f098289@github.com>
 <zsXCn2nynPEIqUg3XFoI_UV_VUoIGyEmvPr2nRwkUiQ=.a3ff867d-cdb3-4a2a-bbcd-69065e3739bb@github.com>
Message-ID: <0wbOnb32bfMQybp2M7vDrJpuTDCIrpKzvUy0KYGHtMU=.ec15027b-8a36-4402-ac33-330383d98e48@github.com>

On Tue, 15 Oct 2024 22:31:27 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch64.ad
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 1634:
> 
>> 1632: 
>> 1633: 
>> 1634: // Copy the small (< 32 byte) haystack to the stack.  Allows for vector reads without page fault
> 
> Just to be pedantic, its `(<=32)` - this function also handles 32bytes case.
> 
> -  line 401: 
> 
>  __ cmpq(haystack_len, 0x20);
>  __ ja(L_bigSwitchTop);
> 
> - though line 293 (`highly_optimized_short_cases`) only seems to route16-byte cases here: 
> ```__ cmpq(haystack_len_p, isU ? 8 : 16);```

I am not sure what you are looking at, but line 293 reads:

__ cmpq(haystack_len_p, isU ? 16 : 32);


for me. IOW, it routes > 32 byte cases to `L_begin`. But the following cmp/ja also routes <= 32 byte cases there, when `needle_len > 6`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1802694667

From rkennke at openjdk.org  Wed Oct 16 09:31:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 09:31:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v43]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Address comments by @vpaprotsk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/005498b1..1fd365df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=41-42

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

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

From sspitsyn at openjdk.org  Wed Oct 16 09:56:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 09:56:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
Message-ID: <mlBy4p_sc9CwuykIxB9ToxKMFLar9G02VMpOlLd1vaY=.457b0b07-732e-40be-8493-84bcd3930767@github.com>

On Tue, 15 Oct 2024 21:26:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 691:
> 
>> 689: 
>> 690:   if (jt->is_in_VTMS_transition()) {
>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
> 
> Suggestion:
> 
>     jvf = check_and_skip_hidden_frames(true, jvf);

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802772384

From sspitsyn at openjdk.org  Wed Oct 16 10:10:15 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 10:10:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
Message-ID: <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>

On Wed, 16 Oct 2024 08:05:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 219:
> 
>> 217:                 public void run() {
>> 218:                     // notify JVMTI
>> 219:                     vthread.notifyJvmtiStart();
> 
> The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.

The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition.
The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame. I'm trying to move the `notifyJvmtiStart/notifyJvmtiEnd` calls to earlier frame to reduce a little bit the scope of VTMS transition. What is the best place to explain it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802793692

From sspitsyn at openjdk.org  Wed Oct 16 10:13:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 10:13:13 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
Message-ID: <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>

On Wed, 16 Oct 2024 08:00:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 423:
> 
>> 421:                 }
>> 422: 
>> 423:             } finally {
> 
> This means an empty finally block, I assume you'll remove the try-finally here.

Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1802799611

From rsunderbabu at openjdk.org  Wed Oct 16 10:30:48 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 16 Oct 2024 10:30:48 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver [v2]
In-Reply-To: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
Message-ID: <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>

> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1

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

  change othervm to driver, remove -Xmx1g

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21519/files
  - new: https://git.openjdk.org/jdk/pull/21519/files/47c105b4..7b3c8847

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

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

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

From kevinw at openjdk.org  Wed Oct 16 11:19:18 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 16 Oct 2024 11:19:18 GMT
Subject: RFR: 8342338: Remove redundant IIOPURLTest.java
Message-ID: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>

This test has been "skipping" since IIOP was removed (jdk 9).  Should be removed, no impact.

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

Commit messages:
 - 8342338: Remove redundant IIOPURLTest.java

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

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

From coleenp at openjdk.org  Wed Oct 16 12:16:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 12:16:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v43]
In-Reply-To: <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
Message-ID: <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>

On Wed, 16 Oct 2024 09:31:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments by @vpaprotsk

We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)

This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2416647209

From stooke at openjdk.org  Wed Oct 16 12:38:15 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 16 Oct 2024 12:38:15 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
 <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
Message-ID: <ipiRBa2STyKDu_5LD6XGuwc4VSPOhn7fikraQvVjGoE=.dd7aeca8-dc72-48b3-bc0c-15578590b665@github.com>

On Tue, 15 Oct 2024 23:52:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clean up test code
>
> test/hotspot/gtest/runtime/test_os.cpp line 422:
> 
>> 420:   errno = 0;
>> 421:   const char* returnedBuffer = os::realpath(nosuchpath, buffer, sizeof(nosuchpath) - 2);
>> 422:   /* Returns ENOENT on Linux, ENAMETOOLONG on Windows */
> 
> Suggestion:
> 
>   /* Reports ENOENT on Linux, ENAMETOOLONG on Windows */
> 
> and similarly below.

The difference is important, thanks - fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1803022082

From stooke at openjdk.org  Wed Oct 16 12:45:14 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 16 Oct 2024 12:45:14 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
 <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
Message-ID: <rNNIes_4xIZ0hKQlIzRvk03SSh5etQLRyGfXsjx9UNk=.43b078a9-21d5-466e-b502-6f5f8a5eddb1@github.com>

On Wed, 16 Oct 2024 00:02:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clean up test code
>
> test/hotspot/gtest/runtime/test_os.cpp line 413:
> 
>> 411: 
>> 412: TEST_VM(os, realpath) {
>> 413:   /* POSIX requires that the file exists, Windows doesn't */
> 
> I'm not sure what this comment means. I can't fully discern from
> 
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fullpath-wfullpath?view=msvc-170
> 
> what Windows does if the path does not exist.

I can only report by example - on my local machine, Windows doesn't appear to care if the file exists or not, but according to the docs you point to, Windows **does** care if the drive letter is valid.
Adding an invalid drive letter test is beyond the current scope of this test.
I have expanded this comment to be more explanatory:

`// POSIX requires that the file exists; `
`// Windows tests for a valid drive letter but may or may not test if the file exists.`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1803033957

From stooke at openjdk.org  Wed Oct 16 12:54:48 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 16 Oct 2024 12:54:48 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v21]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <hLCDTb6euoZT2wSLEmH0i5p-0AOGh9JjrREers7bzZU=.aafa6bd5-9431-42ff-a4d7-eb397f5ed906@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  clean up comments per PR review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/b7e6043f..fbafbf07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=19-20

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

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

From stooke at openjdk.org  Wed Oct 16 12:54:49 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 16 Oct 2024 12:54:49 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
 <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
Message-ID: <M4EfaJJvbjPhCE-Q9uOgq7-g4_-ZUi94AfvMGR5GKCU=.14035883-1b11-4af3-b422-c7389e806bbe@github.com>

On Wed, 16 Oct 2024 00:03:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clean up test code
>
> Hi @stooke , I was away on vacation when you made the updates.
> 
> I'm afraid I still have some issues about expected behaviour on Windows with regard to the tests.

@dholmes-ora thank you for your comments.  I have updated the comments (and reformatted comments and #ifdef code to match the rest of the tests source.

> test/hotspot/gtest/runtime/test_os.cpp line 425:
> 
>> 423:   EXPECT_TRUE(returnedBuffer == nullptr);
>> 424: #if defined(_WINDOWS)
>> 425:   EXPECT_TRUE(errno == ENAMETOOLONG);
> 
> Why is this the case? Our implementation does not set it and `_fullpath` makes no mention of it.

This is Windows behaviour - Windows 10 with VS 2022 at least.  The existence of a file is not checked, but that non-existent filename better fit into the given buffer!

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

PR Comment: https://git.openjdk.org/jdk/pull/20683#issuecomment-2416757362
PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1803043747

From stooke at openjdk.org  Wed Oct 16 13:17:48 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Wed, 16 Oct 2024 13:17:48 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v22]
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <xC3V7LtRLz0esQDKAyKFace0NwJ5WoXjMJmxbCWD-bU=.7a1a8532-759f-420d-8c90-c05b2794e75a@github.com>

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

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

  clean up whitespace error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20683/files
  - new: https://git.openjdk.org/jdk/pull/20683/files/fbafbf07..14679170

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20683&range=20-21

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

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

From weijun at openjdk.org  Wed Oct 16 13:32:24 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 16 Oct 2024 13:32:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

`java.security.jgss`, `jdk.security.auth`, and `jdk.security.jgss` look mostly fine except for [one question](https://github.com/openjdk/jdk/pull/21498#pullrequestreview-2372476763).

src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:

> 29: 
> 30: /**
> 31:  * This class is for GSS security context permissions.

Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2372479736
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803106645

From aturbanov at openjdk.org  Wed Oct 16 13:41:14 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 16 Oct 2024 13:41:14 GMT
Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes
 needlessly long to run [v3]
In-Reply-To: <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
References: <JqU7RWRWbiANIOGXqhqxhFYZ24a1WDcBaoaJIMZeBHs=.5fadb927-c8d8-40cb-b4c3-14aad58547a7@github.com>
 <WylBJgBkTUpkLIts-PC0CH5NBUT2B6bolaH3KnlVSdw=.8f24e310-a295-4572-92c2-a66918af0eb7@github.com>
Message-ID: <0BlxZIs7lCc95XQttzPmj-v1UZSvQnXA4aUCBTwk9Vg=.3edb935f-2441-437f-af8f-243603a2eba0@github.com>

On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl <duke at openjdk.org> wrote:

>> The fix is twofold.
>> 
>> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting.
>> 
>> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration.
>> 
>> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s.
>> 
>> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it.
>> 
>> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both
>> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`.
>> 
>> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help.
>
> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Have EventGeneratorLoop end after a more predictable duration

test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java line 176:

> 174:     // 1. mount /tmp from the main container using --volumes-from.
> 175:     // 2. access /tmp from the main container via /proc/<pid>/root/tmp.
> 176:     private static OutputAnalyzer runSideCar(MainContainer mainContainer, AttachStrategy attachStrategy, boolean elevated,  String whatToRun, String... args) throws Exception {

Suggestion:

    private static OutputAnalyzer runSideCar(MainContainer mainContainer, AttachStrategy attachStrategy, boolean elevated, String whatToRun, String... args) throws Exception {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21331#discussion_r1803124755

From rkennke at openjdk.org  Wed Oct 16 13:46:25 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 13:46:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v43]
In-Reply-To: <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
 <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
Message-ID: <-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>

On Wed, 16 Oct 2024 12:13:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
> 
> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.

Thanks for pointing this out. I've problem-listed both tests on aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2416881886

From rkennke at openjdk.org  Wed Oct 16 13:46:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 13:46:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v44]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Problem-list SharedBaseAddress tests on aarch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1fd365df..ec42f4d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=42-43

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

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

From alanb at openjdk.org  Wed Oct 16 14:41:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 14:41:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
 <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
Message-ID: <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>

On Wed, 16 Oct 2024 10:10:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 423:
>> 
>>> 421:                 }
>>> 422: 
>>> 423:             } finally {
>> 
>> This means an empty finally block, I assume you'll remove the try-finally here.
>
> Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.

Changing the run method to

vthread.notifyJvmtiStart();
try {
    vthread.run(task);
} finally {
    vthread.notifyJvmtiEnd();
}

is okay. I was initially puzzled because the run method is already`@Hidden` but I don't think this is used by JVMTI.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803248925

From alanb at openjdk.org  Wed Oct 16 14:53:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 14:53:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
Message-ID: <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>

On Wed, 16 Oct 2024 10:07:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 219:
>> 
>>> 217:                 public void run() {
>>> 218:                     // notify JVMTI
>>> 219:                     vthread.notifyJvmtiStart();
>> 
>> The notifyJvmtiMount and notifyJvmtiUnmount (native) methods already have the annotations. Is it really required on the caller too?  I'm wondering if the comment on JvmtiMountTransition needs to be expanded to explain this.
>
> The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition. The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame because such requests cause problems because they are not used to post a `FramePop` events nor they are properly cleared. The annotation `@JvmtiMountTransition` is needed to help with this. I'm trying to move the `notifyJvmtiStart()/notifyJvmtiEnd()` calls to earlier frame to reduce a little bit the scope of VTMS transition. What do you think is the best place to explain it? Would placed a comment before annotation `@JvmtiMountTransition` for method `java/lang/VirtualThread$VThreadContinuation$1.run()` good enough?

No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803270431

From coleenp at openjdk.org  Wed Oct 16 15:32:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:32:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v44]
In-Reply-To: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
Message-ID: <jcJX7xDf0w0wDgFA-eoYVaK0rEgIUHTmbpgHiOUZEVw=.1b4528e8-805a-4914-928b-4fd906668204@github.com>

On Wed, 16 Oct 2024 13:46:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problem-list SharedBaseAddress tests on aarch64

Marked as reviewed by coleenp (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2372873633

From duke at openjdk.org  Wed Oct 16 15:34:24 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 16 Oct 2024 15:34:24 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
Message-ID: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>

On Wed, 16 Oct 2024 06:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks, will fix.
>
> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.

**SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.

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

See?also:
- https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803352590

From coleenp at openjdk.org  Wed Oct 16 15:45:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 16 Oct 2024 15:45:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v44]
In-Reply-To: <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
Message-ID: <cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>

On Wed, 16 Oct 2024 13:46:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Problem-list SharedBaseAddress tests on aarch64

src/hotspot/share/oops/compressedKlass.cpp line 185:

> 183: #endif
> 184: 
> 185:   DEBUG_ONLY(sanity_check_after_initialization();)

This is here twice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1803363047

From alanb at openjdk.org  Wed Oct 16 15:56:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 16 Oct 2024 15:56:26 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
Message-ID: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>

On Wed, 16 Oct 2024 15:31:49 GMT, ExE Boss <duke at openjdk.org> wrote:

>> SecurityManager::getClassContext hasn't been needed since JDK 9 but we decided to keep the implementation in case there are older versions of logging libraries that extend SecurityManager so they can call this method. What we have currently in the jep486 is okay, it would be a bit more efficient if method info is dropped, but I think mostly we want to have any remaining usages of this method to move to StackWalker.
>
> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
> 
> --------------------------------------------------------------------------------
> 
> See?also:
> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565

We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803388208

From rkennke at openjdk.org  Wed Oct 16 16:04:21 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 16 Oct 2024 16:04:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v45]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra sanity check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/ec42f4d6..e4c08780

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=44
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=43-44

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

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

From lmesnik at openjdk.org  Wed Oct 16 16:33:18 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 16 Oct 2024 16:33:18 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver [v2]
In-Reply-To: <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
 <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
Message-ID: <FVjq5HCEKglS2Zx0g9rtjfGvIustnO4uKD7yBrk1W_k=.567f20dd-d7f8-4b40-87c0-da06f4c2fb5f@github.com>

On Wed, 16 Oct 2024 10:30:48 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Passing "-Xmx1g -Xcomp" to the LingeredApp.
>> Testing: tier1
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change othervm to driver, remove -Xmx1g

Please check that test pass with options from CI.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21519#pullrequestreview-2373050348

From cjplummer at openjdk.org  Wed Oct 16 17:03:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 16 Oct 2024 17:03:13 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver [v2]
In-Reply-To: <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
 <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
Message-ID: <woCoKtMKfU-CRX8JH14hGQ0DmrWqfVUgoenV8Of_YCg=.d25fbd9b-3e27-4a3b-ba4a-f114279aa84f@github.com>

On Wed, 16 Oct 2024 10:30:48 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Passing "-Xmx1g -Xcomp" to the LingeredApp.
>> Testing: tier1
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change othervm to driver, remove -Xmx1g

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21519#pullrequestreview-2373138300

From sspitsyn at openjdk.org  Wed Oct 16 17:04:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 17:04:10 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
 <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
Message-ID: <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>

On Wed, 16 Oct 2024 14:50:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The method `java/lang/VirtualThread$VThreadContinuation$1.run()` is starting and finishing in a VTMS transition. The issue is with the JVMTI `NotifyFramePop`. We need a way to disallow adding `FramePop` event requests to its frame because such requests cause problems because they are not used to post a `FramePop` events nor they are properly cleared. The annotation `@JvmtiMountTransition` is needed to help with this. I'm trying to move the `notifyJvmtiStart()/notifyJvmtiEnd()` calls to earlier frame to reduce a little bit the scope of VTMS transition. What do you think is the best place to explain it? Would placed a comment before annotation `@JvmtiMountTransition` for method `java/lang/VirtualThread$VThreadContinuation$1.run()` good enough?
>
> No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.

Got it, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803494459

From sspitsyn at openjdk.org  Wed Oct 16 17:18:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 17:18:12 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
Message-ID: <GH6Lkdk_VrzpvduntPwY9UqIU0ToczM26x4N3Zo-_2o=.21352569-e25a-4b67-9969-d657888df1ba@github.com>

On Tue, 15 Oct 2024 21:21:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1814:
> 
>> 1812:   }
>> 1813:   // pure continuations have no VTMS transitions but they use methods annotated with JvmtiMountTransition
>> 1814:   if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {
> 
> Could you please explain the change (and other similar changes in jvmtiExport.cpp)
> Before events were not posted for any `@JvmtiMountTransition` methods, and now only for virtual threads? I.e. events for `@JvmtiMountTransition` methods of carrier threads are posted?

Good question. Some `jvmtiNotify*` notifications can be called in a context of carrier thread and exited in a context of virtual thread and vice versa. So, you are right we should not post these events for `@JvmtiMountTransition` methods, in a context of carrier threads.

So, we need to adjust these conditions even more with something like below:

-  if ((mh->jvmti_mount_transition() && state->is_virtual()) || thread->is_in_any_VTMS_transition()) {
+  if ((mh->jvmti_mount_transition() && (state->is_virtual() || thread->last_continuation() == nullptr)) ||
+    thread->is_in_any_VTMS_transition()) {
     return; // no events should be posted if thread is in any VTMS transition
   }

The check for `thread->last_continuation() == nullptr` will help to skip these events for carrier threads as well but won't skip them for pure continuations. In fact, I do not like the complexity of this check. :(

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803512093

From joehw at openjdk.org  Wed Oct 16 18:03:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 16 Oct 2024 18:03:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <8MHic1Yb7xtxtU0HM8yKLAjD2pYzTWs6Z6G-Adsqcvg=.e5ea6cd4-c3bd-44cb-9b9c-c87ed2f3d0b7@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Changes in source src/java.xml, JAXP tests under test/jaxp, look good. I double-checked my notes on the test changes, they were mostly about removing the runs with Security Manager.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2373273367

From cjplummer at openjdk.org  Wed Oct 16 18:20:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 16 Oct 2024 18:20:10 GMT
Subject: RFR: 8342338: Remove redundant IIOPURLTest.java
In-Reply-To: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
References: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
Message-ID: <tvWzi9uuLeqvwXanvJna6v2CeXX4UfihyKRGuSXSdFU=.c93bc14a-88f8-40cf-ba25-b7557ea54954@github.com>

On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been "skipping" since IIOP was removed (jdk 9).  Should be removed, no impact.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21534#pullrequestreview-2373312903

From amenkov at openjdk.org  Wed Oct 16 18:25:13 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Oct 2024 18:25:13 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
Message-ID: <7kc-gU5npzVYw5K5U3Dk8TG9aUJIaxt6vyc73FLYyYI=.f0583411-545f-46b8-a064-e00c19143849@github.com>

On Wed, 16 Oct 2024 02:28:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: resolved comments from Alex and Chris

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2373324281

From amenkov at openjdk.org  Wed Oct 16 18:28:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Oct 2024 18:28:12 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
Message-ID: <UgxzsVp0cCB-TeCCyexUcdQfwS2MGlenPBzHxVyUuXA=.064613ac-7e6b-4b4a-9204-f4c9dfb65054@github.com>

On Wed, 16 Oct 2024 02:28:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: resolved comments from Alex and Chris

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 160:

> 158:   err= jvmti->NotifyFramePop(thread, 0);
> 159:   if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERROR_DUPLICATE) {
> 160:     LOG("\nNotifyFramePop for method %d returned acceptable error: %s\n", name, TranslateError(err));

format for 1st arg (name) should be `%s`
Suggestion:

    LOG("\nNotifyFramePop for method %s returned acceptable error: %s\n", name, TranslateError(err));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803604095

From mdonovan at openjdk.org  Wed Oct 16 18:52:52 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 16 Oct 2024 18:52:52 GMT
Subject: RFR: 8341927: Remove hardcoded SunJCE provider
Message-ID: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>

In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:

Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

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

Commit messages:
 - 8341927: Remove hardcoded SunJCE provider

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

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

From mullan at openjdk.org  Wed Oct 16 20:17:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:17:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
Message-ID: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>

On Wed, 16 Oct 2024 15:53:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> **SLF4J** currently?depends on?this?method when?logger?name mismatch?detection is?enabled.
>> 
>> --------------------------------------------------------------------------------
>> 
>> See?also:
>> - https://github.com/qos-ch/slf4j/pull/271#issuecomment-1288128565
>
> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.

Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803740577

From duke at openjdk.org  Wed Oct 16 20:42:31 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Wed, 16 Oct 2024 20:42:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v45]
In-Reply-To: <nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <nXvefC2q0Zv4iZH5NdDzBC_sxM3weHdrZpC6vPmUJGM=.c2ddaf31-6b8c-407c-b2a2-ab710486092c@github.com>
Message-ID: <Q7F4DYDHbZ5PFV9p0aI7CJRgiWRUIB58IEBiPkVlQ3Y=.60539a7f-7eea-42d9-b453-508e6d9cdf7b@github.com>

On Wed, 16 Oct 2024 16:04:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra sanity check

Looks good to me (reviewed just `src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp`)
Thanks!

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

Marked as reviewed by vpaprotsk at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2373635524

From mullan at openjdk.org  Wed Oct 16 20:45:38 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:45:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
Message-ID: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>

On Wed, 16 Oct 2024 06:58:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I will revert it.
>
> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.

Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803774792

From mullan at openjdk.org  Wed Oct 16 20:54:21 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 16 Oct 2024 20:54:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
Message-ID: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>

On Wed, 16 Oct 2024 13:28:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
> 
>> 29: 
>> 30: /**
>> 31:  * This class is for GSS security context permissions.
> 
> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.

In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.

If there are other Permission classes you think should have their text modified or removed, let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1803784698

From sspitsyn at openjdk.org  Wed Oct 16 21:35:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 21:35:13 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
Message-ID: <YPPZC3V_vOYyzZYGH1So3idNb0sljMR77lQjBbpDWlc=.5e0a9375-8b8c-462c-bd8b-eb6b45a7c237@github.com>

On Wed, 16 Oct 2024 08:00:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 221:
> 
>> 219:                     vthread.notifyJvmtiStart();
>> 220: 
>> 221:                     vthread.run(task);
> 
> This doesn't look right, it needs to use try-finally.

The discussion on this is on the next comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803823069

From sspitsyn at openjdk.org  Wed Oct 16 21:35:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 21:35:14 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <JaSHY85E3PNCC2fTcx7tYRVnScWK6_xxljYPq8jpKhU=.a93bfee2-4d69-49d5-b0f5-58cdf38be197@github.com>
 <NsgSgLhaiapaU1V95cAeyu0G8Tw1nHr2LN4kductRGk=.827476cf-272f-4e73-9410-f63c0e510b06@github.com>
 <o14TpC8BDBHSu7XLm5HD1rT09n1_QOA4JiWdrAZaXQU=.40a2907b-4411-41cb-aa33-4bac68816551@github.com>
Message-ID: <WMfl08hvl1oyOU095Gw6suO8h5BaM_FHwN8ZkgFmbLo=.2cd9f2cc-192c-4028-a4b7-c2497435b108@github.com>

On Wed, 16 Oct 2024 14:38:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thank you for the comment. I can move the try-finally to the method `java/lang/VirtualThread$VThreadContinuation$1.run()` if you prefer. But it will play the same role functionally.
>
> Changing the run method to
> 
> vthread.notifyJvmtiStart();
> try {
>     vthread.run(task);
> } finally {
>     vthread.notifyJvmtiEnd();
> }
> 
> is okay. I was initially puzzled because the run method is already`@Hidden` but I don't think this is used by JVMTI.

Thanks. Yes, the annotation `@Hidden` is not used by the JVMTI. It would be tricky to use it consistently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803823267

From cjplummer at openjdk.org  Wed Oct 16 22:00:18 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 16 Oct 2024 22:00:18 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
Message-ID: <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>

On Wed, 16 Oct 2024 02:28:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: resolved comments from Alex and Chris

Have you verified that the test still detects the bug? In other words, if you disabled the fix, does the test fail? I was just a bit worried that with all the changes to it, it might not be still be properly detecting the bug, and I looked in the mach5 history and don't see this test failing for a couple of weeks now.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @summary JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning

Would be good to also add an `@bug` statement.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 84:

> 82:       deallocate(jvmti, jni, name);
> 83:       deallocate(jvmti, jni, (void*)last_notify_method);
> 84:       fatal(jni, "FramePop event in wrong method\n");

This is the main purpose for this test. It used to just set `failed` and then continue to run to detect additional errors, and then java side of the test calls `failed()` to detect the failure. Now you exit the test process when there is a failure. There is actually no purpose served for the `failed` flag anymore.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 99:

> 97:   res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_9);
> 98:   if (res != JNI_OK || jvmti == nullptr) {
> 99:     LOG("GetEnv(JVMTI_VERSION_9) failedL error(%d)", res);

Suggestion:

    LOG("GetEnv(JVMTI_VERSION_9) failed: error(%d)", res);

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

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2373700405
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803809612
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803839032
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803826652

From cjplummer at openjdk.org  Wed Oct 16 22:18:14 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 16 Oct 2024 22:18:14 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v2]
In-Reply-To: <x01CSb6rYEnhPy78xvvd36hqq9QT0Xca1nCPLGz6SPg=.5d9d7d1c-d0f3-49a5-a057-0156fe7ce5af@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
 <x01CSb6rYEnhPy78xvvd36hqq9QT0Xca1nCPLGz6SPg=.5d9d7d1c-d0f3-49a5-a057-0156fe7ce5af@github.com>
Message-ID: <Dfol0qTe4TSxEIWYaOEnkGmhAseolRfZNOv4-4M_RQU=.a008b1b8-70dc-44b2-ab26-b94169e70923@github.com>

On Wed, 16 Oct 2024 09:12:56 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Man page update for jcmd.
>> 
>> Add updates for the filename options/arguments affected by:
>> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
>> 
>> Also:
>> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
>> 
>> In Description:
>> Each diagnostic command has its own set of options and arguments .
>>  
>> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
>> 
>> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.
>
> 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:
> 
>  - Update JFR commands for FILE
>  - Merge remote-tracking branch 'upstream/master' into 8337276_jcmd_pid_manpage
>  - 8337276: jcmd man page update for PID in output filenames

src/jdk.jcmd/share/man/jcmd.1 line 974:

> 972: \f[I]filename\f[R]: (Optional) Name of the shared archive to be dumped.
> 973: If %p is specified in the filename, it is expanded to the JVM\[aq]s PID.
> 974: (FILE, \[dq]java_pid%p_<subcmd>.jsa\[dq])

The paragraph below this goes into details on how the default path is generated even though it is implied by the above help. We don't do this extra explanation for other places where the filename has a default, so probably not needed here, but I suppose it doesn't hurt either.

Also, two paragraphs below is a discussions about absolute paths that also applies to all other uses of filename. If it is necessary here, then that implies it is necessary in the other locations too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20401#discussion_r1803858444

From sspitsyn at openjdk.org  Wed Oct 16 22:38:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 16 Oct 2024 22:38:11 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <Q2tEciRpTyuOA29lYfVm6beY-Msesu611sI3vxDqJuM=.3701f62b-4f11-4352-87e8-fa99a896aed8@github.com>
 <ZRUxgwPVnJGTEpvUCRz_sR-b6-LcnJeK5cl_bo9037M=.84eca85d-a9a3-4a2d-ba95-8c8bfa56a241@github.com>
Message-ID: <B2BCbltQWn5L4x0qVMQ75Dyl56j6ZakN2okM5Xt8hl4=.ad0bb373-dfa7-4f45-a469-f0eb944f0bc5@github.com>

On Tue, 15 Oct 2024 21:59:41 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
>> 
>>> 690:   if (jt->is_in_VTMS_transition()) {
>>> 691:     jvf = check_and_skip_hidden_frames(jt->is_in_VTMS_transition(), jvf);
>>> 692:   } else if (is_virtual) { // filter out pure continuations
>> 
>> Not sure I follow the logic here.
>> As far as I understand yield/yield need to be filtered out only for unmounted virtual threads. But `is_virtual` here means we have mounted VT?
>> Looks like almost all callers call this method only if `jt->is_in_JTMS_transilition()` is true
>> Exception is a call from `get_vthread_jvf()` when vthread is mounted.
>
> This seems to be a good catch. The call to `skip_top_jvmti_annotated_frames()` should not be needed.
> It does not harm either, so I've added it for safety.
> Will remove it and rerun mach5 tiers to make sure there is nothing unexpected.

Please, hold on. My last comment was not fully incorrect.
Not only `yield()/yield0()` need to be filtered out for virtual threads.
There are more cases for a `JavaThread` which is not in a VTMS transition executing a virtual thread. All the calls below represents inconsistency and must be hidden:

 - `notifyJvmtiStart()`: This function is called in a VTMS MOUNT transition which it ends. So its return happens with the thread identity `VIRTUAL`.
 - `notifyJvmtiEnd()`: This function is called with the thread identity `VIRTUAL`. It is starting a VTMS UNMOUNT transition, so its return happens in a VTMS transition.
 - `notifyJvmtiMount(false)`:  This call happens in a VTMS transition. It finishes the VTMS transition and its return happen with the thread identity 'VIRTUAL'.
 - `notifyJvmtiUnmount(true)`:  This call happens with the thread identity 'VIRTUAL'. It starts a VTMS UNMOUNT transition, so its return happens in a VTMS transition.

I've just discovered that we have two more cases to hide frames for carrier threads that are NOT in a VTMS transitions:
- `notifyJvmtiMount(true)`: This call happens with the thread identity `CARRIER`. It starts a VTMS MOUNT transition, so its return happens in a VTMS transition.
 - `notifyJvmtiUnmount(false)`:  This call happens in a VTMS UNMOUNT transition. It finishes transition, so its return happens with the thread identity `CARRIER`.

An update is needed for these two cases.
All the cases above can be potentially observed at a safepoint/handshake in a non-transitioned state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1803874831

From amenkov at openjdk.org  Wed Oct 16 22:39:12 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 16 Oct 2024 22:39:12 GMT
Subject: RFR: 8342338: Remove redundant IIOPURLTest.java
In-Reply-To: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
References: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
Message-ID: <SwN0PoST_D9RZ0E5_BLZoCSjagqCd6qbP8c6IJZDvu4=.1883b13e-5f01-415e-a9ce-cf804f603b17@github.com>

On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been "skipping" since IIOP was removed (jdk 9).  Should be removed, no impact.

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21534#pullrequestreview-2373803823

From sspitsyn at openjdk.org  Thu Oct 17 00:49:23 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 00:49:23 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
Message-ID: <r9sLJ2ZkzMN1aV7TsfjprJM7qNy0k9Hd0ym_wzpcG9Q=.fbe76aa0-eee4-45c8-9c8d-1ab803a0d515@github.com>

On Wed, 16 Oct 2024 21:36:02 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: resolved comments from Alex and Chris
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 99:
> 
>> 97:   res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_9);
>> 98:   if (res != JNI_OK || jvmti == nullptr) {
>> 99:     LOG("GetEnv(JVMTI_VERSION_9) failedL error(%d)", res);
> 
> Suggestion:
> 
>     LOG("GetEnv(JVMTI_VERSION_9) failed: error(%d)", res);

Thanks, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803965649

From dholmes at openjdk.org  Thu Oct 17 00:51:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Oct 2024 00:51:25 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v22]
In-Reply-To: <xC3V7LtRLz0esQDKAyKFace0NwJ5WoXjMJmxbCWD-bU=.7a1a8532-759f-420d-8c90-c05b2794e75a@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <xC3V7LtRLz0esQDKAyKFace0NwJ5WoXjMJmxbCWD-bU=.7a1a8532-759f-420d-8c90-c05b2794e75a@github.com>
Message-ID: <-t3ExBCWpxExd61f5HpzxvdFnAF3yG_vfwh7u_na6I8=.09807a1c-6c28-4007-8d7b-172391865a4d@github.com>

On Wed, 16 Oct 2024 13:17:48 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
>> 
>> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
>> 
>> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
>> 
>> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up whitespace error

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20683#pullrequestreview-2373927879

From dholmes at openjdk.org  Thu Oct 17 00:51:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 17 Oct 2024 00:51:26 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v20]
In-Reply-To: <M4EfaJJvbjPhCE-Q9uOgq7-g4_-ZUi94AfvMGR5GKCU=.14035883-1b11-4af3-b422-c7389e806bbe@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <bnF0WdslqAL-OkwmoQvZbz2FzuKmkjBkppWn4qQfTbQ=.52a6889a-dad7-4f59-a27c-827127865ff2@github.com>
 <ARS6uzE_3yKLHf8NAdnexMTK6j7S7JQ4LyX8IaDq8aI=.94b43d4f-d1dc-4192-8169-636a8c56ca24@github.com>
 <M4EfaJJvbjPhCE-Q9uOgq7-g4_-ZUi94AfvMGR5GKCU=.14035883-1b11-4af3-b422-c7389e806bbe@github.com>
Message-ID: <IPLimGiNkApajEl9lgTeMfIH_V88_E5N-dOMxs2MmgE=.569944ca-7449-41ee-8f98-f75a7cff74c7@github.com>

On Wed, 16 Oct 2024 12:49:34 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> test/hotspot/gtest/runtime/test_os.cpp line 425:
>> 
>>> 423:   EXPECT_TRUE(returnedBuffer == nullptr);
>>> 424: #if defined(_WINDOWS)
>>> 425:   EXPECT_TRUE(errno == ENAMETOOLONG);
>> 
>> Why is this the case? Our implementation does not set it and `_fullpath` makes no mention of it.
>
> This is Windows behaviour - Windows 10 with VS 2022 at least.  The existence of a file is not checked, but that non-existent filename better fit into the given buffer!

Okay. This behaviour is not specified but the test passed on our CI on Windows Server 2016 and 2019.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20683#discussion_r1803965341

From sspitsyn at openjdk.org  Thu Oct 17 00:53:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 00:53:18 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
Message-ID: <3Av7YLB236vlrbJjE38hZ91dj8_fIs3uB7VUD3IKnwM=.030427c4-87f8-490d-9e82-a2d599e143c0@github.com>

On Wed, 16 Oct 2024 21:16:53 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: resolved comments from Alex and Chris
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @summary JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning
> 
> Would be good to also add an `@bug` statement.

Thanks. Added @bug line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803967533

From sspitsyn at openjdk.org  Thu Oct 17 01:00:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 01:00:18 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
Message-ID: <NsvZaq1ROwCeP42nFiy6e1421TflTajkOZAM9zHCBZU=.ef7bcb1a-ca4c-47fa-aef3-b3eb9ac74eeb@github.com>

On Wed, 16 Oct 2024 21:50:19 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: resolved comments from Alex and Chris
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 84:
> 
>> 82:       deallocate(jvmti, jni, name);
>> 83:       deallocate(jvmti, jni, (void*)last_notify_method);
>> 84:       fatal(jni, "FramePop event in wrong method\n");
> 
> This is the main purpose for this test. It used to just set `failed` and then continue to run to detect additional errors, and then java side of the test calls `failed()` to detect the failure. Now you exit the test process when there is a failure. There is actually no purpose served for the `failed` flag anymore.

> Have you verified that the test still detects the bug? In other words, if you disabled the fix, does the test fail? I was just a bit worried that with all the changes to it, it might not be still be properly detecting the bug, and I looked in the mach5 history and don't see this test failing for a couple of weeks now.

The test is failing locally with event in a wrong method as expected.
But the latest changes broke the test. Now it is failing at `deallocate(jvmti, jni, csig)`.
I suspect it is related to the latest changes for `last_notify_method` but have not proved it yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803970580

From sspitsyn at openjdk.org  Thu Oct 17 01:00:19 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 01:00:19 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <NsvZaq1ROwCeP42nFiy6e1421TflTajkOZAM9zHCBZU=.ef7bcb1a-ca4c-47fa-aef3-b3eb9ac74eeb@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
 <NsvZaq1ROwCeP42nFiy6e1421TflTajkOZAM9zHCBZU=.ef7bcb1a-ca4c-47fa-aef3-b3eb9ac74eeb@github.com>
Message-ID: <_6ruhHPFGx8cuBC9HW3kKVEhMmBjLfodszknBr5GniE=.feb866ba-4c3e-4dad-bb1e-82f508d35d4e@github.com>

On Thu, 17 Oct 2024 00:55:58 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 84:
>> 
>>> 82:       deallocate(jvmti, jni, name);
>>> 83:       deallocate(jvmti, jni, (void*)last_notify_method);
>>> 84:       fatal(jni, "FramePop event in wrong method\n");
>> 
>> This is the main purpose for this test. It used to just set `failed` and then continue to run to detect additional errors, and then java side of the test calls `failed()` to detect the failure. Now you exit the test process when there is a failure. There is actually no purpose served for the `failed` flag anymore.
>
>> Have you verified that the test still detects the bug? In other words, if you disabled the fix, does the test fail? I was just a bit worried that with all the changes to it, it might not be still be properly detecting the bug, and I looked in the mach5 history and don't see this test failing for a couple of weeks now.
> 
> The test is failing locally with event in a wrong method as expected.
> But the latest changes broke the test. Now it is failing at `deallocate(jvmti, jni, csig)`.
> I suspect it is related to the latest changes for `last_notify_method` but have not proved it yet.

> This is the main purpose for this test. It used to just set failed and then continue to run to detect additional errors, and then java side of the test calls failed() to detect the failure. Now you exit the test process when there is a failure. There is actually no purpose served for the failed flag anymore.

Okay, I'll try to remove `fatal()` and retest it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1803971275

From sspitsyn at openjdk.org  Thu Oct 17 02:33:01 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 02:33:01 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review test tweaks: add @bug tag; a reliability update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/3b82454f..dc457681

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

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

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

From alanb at openjdk.org  Thu Oct 17 05:57:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 05:57:21 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
Message-ID: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>

On Wed, 16 Oct 2024 20:14:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> We've had logging library maintainers on the core-libs-dev several times in the last 7+ years so I hope there is good awareness of StackWalker. SM.getClassContext is legacy, shouldn't be any reason to use it in 2024.
>
> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.

Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804151450

From duke at openjdk.org  Thu Oct 17 07:16:16 2024
From: duke at openjdk.org (duke)
Date: Thu, 17 Oct 2024 07:16:16 GMT
Subject: RFR: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows [v22]
In-Reply-To: <xC3V7LtRLz0esQDKAyKFace0NwJ5WoXjMJmxbCWD-bU=.7a1a8532-759f-420d-8c90-c05b2794e75a@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
 <xC3V7LtRLz0esQDKAyKFace0NwJ5WoXjMJmxbCWD-bU=.7a1a8532-759f-420d-8c90-c05b2794e75a@github.com>
Message-ID: <cXIHZDH6duiQ2ItfJy3lK2DNqscUSD1we2Dpxae2tRk=.a90ea1e0-6e2c-44ff-ab1c-2b743ee8f870@github.com>

On Wed, 16 Oct 2024 13:17:48 GMT, Simon Tooke <stooke at openjdk.org> wrote:

>> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
>> 
>> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
>> 
>> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
>> 
>> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up whitespace error

@stooke 
Your change (at version 1467917002d5efd11ebbdb8825cb0e4789b9225c) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20683#issuecomment-2418745864

From kevinw at openjdk.org  Thu Oct 17 08:04:16 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 17 Oct 2024 08:04:16 GMT
Subject: RFR: 8342338: Remove redundant IIOPURLTest.java
In-Reply-To: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
References: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
Message-ID: <csOMtFGTm83kxydbxV3JzaYFTLwxKJMRg82mcMsdaYk=.ef991ffb-d109-4068-9fdc-67f2cdf29588@github.com>

On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been "skipping" since IIOP was removed (jdk 9).  Should be removed, no impact.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21534#issuecomment-2418837171

From kevinw at openjdk.org  Thu Oct 17 08:04:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 17 Oct 2024 08:04:17 GMT
Subject: Integrated: 8342338: Remove redundant IIOPURLTest.java
In-Reply-To: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
References: <Ufib2Ao1pjllwBZ44nd8OlOFsNdGLzpyvMPIvSaAB54=.ecf92705-f9f2-47c7-b216-af0d12b014e6@github.com>
Message-ID: <hFsPLyfkUsiXE_bm6Tq2Bnsgbvsb2U-snImICcjd8lI=.c8d63825-b120-45d6-9386-0c7d79dbbca9@github.com>

On Wed, 16 Oct 2024 11:14:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test has been "skipping" since IIOP was removed (jdk 9).  Should be removed, no impact.

This pull request has now been integrated.

Changeset: 8862ca07
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8862ca076f9be1c0b5f4bc2639ab9c1f60de308c
Stats:     79 lines in 1 file changed: 0 ins; 79 del; 0 mod

8342338: Remove redundant IIOPURLTest.java

Reviewed-by: cjplummer, amenkov

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

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

From stooke at openjdk.org  Thu Oct 17 08:09:25 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 17 Oct 2024 08:09:25 GMT
Subject: Integrated: 8338851: Hoist os::Posix::realpath() to os::realpath() and
 implement on Windows
In-Reply-To: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
References: <z-bsKQEbS-9XI4Tbg2NfHWSr5canXU80LpoDrqd-Z7E=.c55bbab4-eff2-4576-972d-36952e47b37c@github.com>
Message-ID: <IWFqd_bWzSlYg-nL3JalNCNYS5aPM_zyxOBNIk7ga4E=.f14f4bc4-8314-4471-86c7-7cc24c4f5cae@github.com>

On Thu, 22 Aug 2024 18:36:39 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This PR changes the status of realpath() from a Posix-specific API to a globally available API, i.e. adding it to the "Hotspot Porting API".  Code would refer to os::realpath() instead of os::Posix::realpath().
> 
> This requires a Windows implementation of realpath(), using Windows _fullpath(), and renaming os::Posix::realpath() to os::realpath().
> 
> The main difference between POSIX and Windows behaviour is that POSIX actually requires an existing accessible file, while Windows will happily work with made-up filenames.
> 
> Please note that guidelines for doing this appear in src/hotspot/share/runtime/os.hpp

This pull request has now been integrated.

Changeset: 7a64fbbb
Author:    Simon Tooke <stooke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a64fbbb9292f4d65a6970206dec1a7d7645046b
Stats:     133 lines in 11 files changed: 109 ins; 10 del; 14 mod

8338851: Hoist os::Posix::realpath() to os::realpath() and implement on Windows

Reviewed-by: dholmes, stuefe, jwaters

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

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

From sspitsyn at openjdk.org  Thu Oct 17 09:13:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 09:13:51 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v4]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <21dTiM5lJRCrNIKslnwjIZB4AQBGLiGjPYg4Qckw4OM=.17fa4363-2f09-49eb-898d-47ce71fb0107@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

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

  review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/3317ea81..0ad3fd7a

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

  Stats: 45 lines in 3 files changed: 16 ins; 17 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

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

From sspitsyn at openjdk.org  Thu Oct 17 09:16:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 09:16:31 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v5]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

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

  review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/0ad3fd7a..f8d05152

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

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

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

From mli at openjdk.org  Thu Oct 17 10:07:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 17 Oct 2024 10:07:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v43]
In-Reply-To: <-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <d8BYPKWeRrC0aK7WeqwXe2pphNUZRgqKf23s15leeNE=.8e8e13a2-5f2a-4ee5-86fb-beef1ea64555@github.com>
 <XDTAUAApVTM7iZAGsuosoHPDcEf5NH6rO4JPm1W-YjA=.7cf382e3-f9ca-4d2a-b22e-81f003da88b7@github.com>
 <-8DXPgoraRNtE7uJw-Pdk5Z3eJAzIbhVRJOX5JH85UY=.358823f0-a30f-4994-b566-cdf064eac8f0@github.com>
Message-ID: <I5wW9So_ctsg-umi8UqIV8vWKbFUTHej5n_Jep3G_9Y=.17d468f8-1d13-4ed5-9584-bd097216fe4a@github.com>

On Wed, 16 Oct 2024 13:42:42 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>> 
>> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
>
>> We're seeing failures in our nightly testing for tests runtime/cds/appcds/SharedBaseAddress.java and runtime/cds/SharedBaseAddress.java which I'm tracking in this bug [JDK-8340212](https://bugs.openjdk.org/browse/JDK-8340212)
>> 
>> This patch should problem list these two tests on aarch64 when UseCompactObjectHeaders is on (if possible to be that specific), or just plain problem list it until I have a fix for it.
> 
> Thanks for pointing this out. I've problem-listed both tests on aarch64.

@rkennke Here is the [riscv implementation](https://github.com/rkennke/jdk/compare/JDK-8305895-v4...rivosinc:jdk-compact-2:compact-header-riscv?expand=1#diff-5808bc502bdf55f1ae7ba30504c8ee6eb92527f0c11670a35d6279d671b52c6bR271), could you help to include it in this pr? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2419103904

From duke at openjdk.org  Thu Oct 17 10:36:14 2024
From: duke at openjdk.org (duke)
Date: Thu, 17 Oct 2024 10:36:14 GMT
Subject: RFR: 8339871: serviceability/sa/TestDebugInfoDecode.java should be
 driver [v2]
In-Reply-To: <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
 <2W5k0luFAQlvL7CHOruTy7IAT0LM4EkA4_lyboCki0M=.37c62f45-f251-4f5b-87e0-1918c8657a0a@github.com>
Message-ID: <75ucx7V8fP7CjAj65aFAqq6W1U_qaAMl7Klx6otIDtg=.c88742bf-1424-4d87-bdf1-6360936f8bc4@github.com>

On Wed, 16 Oct 2024 10:30:48 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Passing "-Xmx1g -Xcomp" to the LingeredApp.
>> Testing: tier1
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change othervm to driver, remove -Xmx1g

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

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

PR Comment: https://git.openjdk.org/jdk/pull/21519#issuecomment-2419163375

From rkennke at openjdk.org  Thu Oct 17 10:57:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 17 Oct 2024 10:57:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Compact header riscv (#3)
  
  Implement compact headers on RISCV
  ---------
  
  Co-authored-by: hamlin <hamlin at rivosinc.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/e4c08780..1b907cc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=44-45

  Stats: 136 lines in 10 files changed: 76 ins; 31 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

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

From alanb at openjdk.org  Thu Oct 17 10:58:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 17 Oct 2024 10:58:20 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <bthGrrUY71n71tv6UfX3VBW6c_l867GTfTl-bT0ENpE=.2511deec-1cb3-4fb6-9341-c6ce74747640@github.com>
 <oP42eKZXLmQFgG_DLSDpmui54HISq_KCDnF_uDnNPO0=.e53ee7c4-8c25-4f34-a1d3-dc99cbd16bf2@github.com>
 <Wht-tuuGDZt_XliGWoBzXmQRNiY5xe-nsYusevJtHoE=.e68c0c34-0007-4098-a631-99c640b7f989@github.com>
 <wdqAxZs9snttDKfZBWWy7M9Eu4MfTxG_Musdo7h6NIQ=.bcf31986-8690-4be2-9b1d-bb2aac5aade3@github.com>
Message-ID: <KIphK6l9cXtPiOTaVZkwLCydGuUFlcqYwNj8QSfxXsE=.9a55f32d-88d9-4411-822c-58236673dec2@github.com>

On Wed, 16 Oct 2024 17:01:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> No issue from me on moving the notifications to the run method. My comment was more for the JvmtiMountTransition's class description as it's not easy to audit the use of this annotation.
>
> Got it, thanks.

The updated changes to VirtualThread look fine. I'm still wondering about JvmtiMountTransition's class description.  There's nothing obvious in yield and yield0 that they start/end a VTMS.  Maybe for a future PR but I think the description could be expanded as the same questions will come up each time that anything using this annotation changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1804553428

From weijun at openjdk.org  Thu Oct 17 11:27:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 17 Oct 2024 11:27:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
Message-ID: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>

On Wed, 16 Oct 2024 20:51:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/jdk.security.jgss/share/classes/com/sun/security/jgss/InquireSecContextPermission.java line 31:
>> 
>>> 29: 
>>> 30: /**
>>> 31:  * This class is for GSS security context permissions.
>> 
>> Why is the content of _this_ class modified? I see in other permission classes the content is left unmodified.
>
> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
> 
> If there are other Permission classes you think should have their text modified or removed, let me know.

All JGSS permission classes follow the same style:

In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.
 ```
In `javax.security.auth.kerberos.DelegationPermission`:

 * This class is used to restrict the usage of the Kerberos
 * delegation model, ie: forwardable and proxiable tickets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1804590136

From tschatzl at openjdk.org  Thu Oct 17 12:35:37 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 17 Oct 2024 12:35:37 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <f8MC9w61VqSlgiSOJSYoKQy1kStQVVnNHBgY7h4BLO8=.1804d5c9-3cdb-4664-812e-e10239917c23@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

Mostly only looked at gc files.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2375093923

From yzheng at openjdk.org  Thu Oct 17 13:07:32 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 17 Oct 2024 13:07:32 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <1Bg-C0suC9IfxXU-2Yw5pvXwySVaEFCg6EpiVgsSw70=.f6f0d596-b465-4137-99de-fba8236e8908@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

JVMCI changes look good!

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2375182126

From rsunderbabu at openjdk.org  Thu Oct 17 14:38:23 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Thu, 17 Oct 2024 14:38:23 GMT
Subject: Integrated: 8339871: serviceability/sa/TestDebugInfoDecode.java should
 be driver
In-Reply-To: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
References: <YAChIFhSBaE7xXEpMdxtTYYsCd8GUCRHyIyWTQExJNI=.c070b8df-cc62-469d-a4f1-2f1052ce0972@github.com>
Message-ID: <EikIORO5_p2LrEeKCGFZt8wjAGvkpulv1sjJH0Btuq8=.186f0c4c-3349-463f-991a-245c9bc9933f@github.com>

On Tue, 15 Oct 2024 10:12:21 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Passing "-Xmx1g -Xcomp" to the LingeredApp.
> Testing: tier1

This pull request has now been integrated.

Changeset: d915ac2a
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d915ac2abda9ff4cd8c7a628f08d7964bcf3f472
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8339871: serviceability/sa/TestDebugInfoDecode.java should be driver

Reviewed-by: cjplummer, lmesnik

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

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

From sspitsyn at openjdk.org  Thu Oct 17 15:44:16 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:44:16 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
Message-ID: <09K5FdOPqPuBS_V-2vF_Nl3nUIcdvXcjcGG_c3ZbyXk=.7d4908fd-e657-4277-99ee-ae651a0da19d@github.com>

On Thu, 17 Oct 2024 02:33:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review test tweaks: add @bug tag; a reliability update

Alex and Chris, thank you a lot for review and comments! Need a re-approval from you for integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/21468#issuecomment-2419894743

From sspitsyn at openjdk.org  Thu Oct 17 15:44:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:44:20 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <_6ruhHPFGx8cuBC9HW3kKVEhMmBjLfodszknBr5GniE=.feb866ba-4c3e-4dad-bb1e-82f508d35d4e@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <Wrgy75xd4utohKIBuHzJuS_XqXXihdxtIsacCyQIBaw=.320ce706-2d0d-47c6-9a53-74802b12d80b@github.com>
 <NsvZaq1ROwCeP42nFiy6e1421TflTajkOZAM9zHCBZU=.ef7bcb1a-ca4c-47fa-aef3-b3eb9ac74eeb@github.com>
 <_6ruhHPFGx8cuBC9HW3kKVEhMmBjLfodszknBr5GniE=.feb866ba-4c3e-4dad-bb1e-82f508d35d4e@github.com>
Message-ID: <3bcalYUPl07gyas5jERmqH6tbVAbHtwzCOHEhSqLpPg=.bacd6509-733b-4aa6-9529-33ad52b2d45b@github.com>

On Thu, 17 Oct 2024 00:57:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> Have you verified that the test still detects the bug? In other words, if you disabled the fix, does the test fail? I was just a bit worried that with all the changes to it, it might not be still be properly detecting the bug, and I looked in the mach5 history and don't see this test failing for a couple of weeks now.
>> 
>> The test is failing locally with event in a wrong method as expected.
>> But the latest changes broke the test. Now it is failing at `deallocate(jvmti, jni, csig)`.
>> I suspect it is related to the latest changes for `last_notify_method` but have not proved it yet.
>
>> This is the main purpose for this test. It used to just set failed and then continue to run to detect additional errors, and then java side of the test calls failed() to detect the failure. Now you exit the test process when there is a failure. There is actually no purpose served for the failed flag anymore.
> 
> Okay, I'll try to remove `fatal()` and retest it.

Fixed the test and re-tested. It looks good now. Mach5 tiers 1-6 are passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805011968

From sspitsyn at openjdk.org  Thu Oct 17 15:44:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:44:21 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v4]
In-Reply-To: <UgxzsVp0cCB-TeCCyexUcdQfwS2MGlenPBzHxVyUuXA=.064613ac-7e6b-4b4a-9204-f4c9dfb65054@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <X0fEmXHiMRQbfh-dncYpYp4RDFM6pIo8G4-d0szCFTI=.5454e3fc-e8d3-4707-aa1a-33000eeae4ef@github.com>
 <UgxzsVp0cCB-TeCCyexUcdQfwS2MGlenPBzHxVyUuXA=.064613ac-7e6b-4b4a-9204-f4c9dfb65054@github.com>
Message-ID: <GtuZ9m8SdvIMoI05epE-wvKs-E2YNaer14A1BFssjSk=.0423b141-e78e-4b50-abb6-421fd0826bcd@github.com>

On Wed, 16 Oct 2024 18:25:46 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: resolved comments from Alex and Chris
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 160:
> 
>> 158:   err= jvmti->NotifyFramePop(thread, 0);
>> 159:   if (err == JVMTI_ERROR_OPAQUE_FRAME || err == JVMTI_ERROR_DUPLICATE) {
>> 160:     LOG("\nNotifyFramePop for method %d returned acceptable error: %s\n", name, TranslateError(err));
> 
> format for 1st arg (name) should be `%s`
> Suggestion:
> 
>     LOG("\nNotifyFramePop for method %s returned acceptable error: %s\n", name, TranslateError(err));

Thanks. I've also discovered and fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805014234

From sspitsyn at openjdk.org  Thu Oct 17 15:56:18 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:56:18 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v5]
In-Reply-To: <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <NDpcFZo0hBSNwnfqJaVuweX3tgcjOcs63XxIDykGdIc=.1a106349-d351-4bb0-8d29-d3ccb68450f4@github.com>
Message-ID: <M6Sa2VzhGAsMAoHWstAHeApRzL4r-WJUMZyVRSxD4rc=.35707321-347a-42db-ba6f-65c23c28ef09@github.com>

On Thu, 17 Oct 2024 09:16:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller

I believe, I've resolved almost all review comments.
Please, let me know if anything is missed or there are some issues in my latest updates.
The mach5 tiers 1-6 are good.

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

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2419922957

From sspitsyn at openjdk.org  Thu Oct 17 15:56:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 15:56:20 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v3]
In-Reply-To: <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <kFsU5acppgM668p-tO8h-y5LEccnIrz_s7gEe82UZ84=.e7e769b0-9d4a-40ce-ac75-9f500f37ce74@github.com>
 <C--1Y2IwP5VwohlfPGo8KGUAi1-BOfIEaI_98ruelZo=.9e01edae-a026-41e6-9db9-5aaf06fa7632@github.com>
Message-ID: <PA6ZSw_0zaN_4yXaiUqY-8vU7ZsY0zlbNlaYQq-FBc0=.0fb7abd7-869c-4926-80b0-b1a771f2432a@github.com>

On Tue, 15 Oct 2024 21:26:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 588:
> 
>> 586:   // There should not be any VTMS transition here. This is for safety.
>> 587:   if (java_thread->is_in_VTMS_transition()) {
>> 588:     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(java_thread, jvf);
> 
> The code now checks `java_thread->is_in_VTMS_transition()`, so it may be simplified to
> Suggestion:
> 
>     jvf = JvmtiEnvBase::check_and_skip_hidden_frames(true, jvf);

Thank you for the comment. Unfortunately, with my latest update it is not relevant anymore.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 753:
> 
>> 751:     // Skip hidden frames only for carrier threads
>> 752:     // which are in non-temporary VTMS transition.
>> 753:     jvf = check_and_skip_hidden_frames(jt, jvf);
> 
> Can be
> Suggestion:
> 
>     jvf = check_and_skip_hidden_frames(true, jvf);

Thank you for the comment. Unfortunately, with my latest update it is not relevant anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1805031938
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1805032070

From kevinw at openjdk.org  Thu Oct 17 15:59:17 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 17 Oct 2024 15:59:17 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v2]
In-Reply-To: <Dfol0qTe4TSxEIWYaOEnkGmhAseolRfZNOv4-4M_RQU=.a008b1b8-70dc-44b2-ab26-b94169e70923@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
 <x01CSb6rYEnhPy78xvvd36hqq9QT0Xca1nCPLGz6SPg=.5d9d7d1c-d0f3-49a5-a057-0156fe7ce5af@github.com>
 <Dfol0qTe4TSxEIWYaOEnkGmhAseolRfZNOv4-4M_RQU=.a008b1b8-70dc-44b2-ab26-b94169e70923@github.com>
Message-ID: <0kHkeULIoGx9dIFezrlO04UaHlu8BI1kWpNi32bduOg=.69f957b3-1f79-4750-b2cd-5257b708e109@github.com>

On Wed, 16 Oct 2024 22:15:05 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Update JFR commands for FILE
>>  - Merge remote-tracking branch 'upstream/master' into 8337276_jcmd_pid_manpage
>>  - 8337276: jcmd man page update for PID in output filenames
>
> src/jdk.jcmd/share/man/jcmd.1 line 974:
> 
>> 972: \f[I]filename\f[R]: (Optional) Name of the shared archive to be dumped.
>> 973: If %p is specified in the filename, it is expanded to the JVM\[aq]s PID.
>> 974: (FILE, \[dq]java_pid%p_<subcmd>.jsa\[dq])
> 
> The paragraph below this goes into details on how the default path is generated even though it is implied by the above help. We don't do this extra explanation for other places where the filename has a default, so probably not needed here, but I suppose it doesn't hurt either.
> 
> Also, two paragraphs below is a discussions about absolute paths that also applies to all other uses of filename. If it is necessary here, then that implies it is necessary in the other locations too.

Yes - both of those paragraphs are _not_very_ useful.

"If `filename` is not specified, a default file name is chosen using the pid..." - this explains how the default filename works.

" If `filename` is not specified as an absolute path, the archive file is created in a directory relative to.." -- Well yes, we are saying that is if it's not absolute, it's relative... Hmm... This does not add much value either.

The good thing is these are not in the live help output, so deleting them does not make the help any more inconsistent.  I think these can both be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20401#discussion_r1805040920

From kevinw at openjdk.org  Thu Oct 17 16:12:26 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 17 Oct 2024 16:12:26 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v3]
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

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

  VM.cds remove unnecessary text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20401/files
  - new: https://git.openjdk.org/jdk/pull/20401/files/7d077a79..9c39c6c9

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

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

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

From mullan at openjdk.org  Thu Oct 17 18:03:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 17 Oct 2024 18:03:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
Message-ID: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>

On Thu, 17 Oct 2024 11:24:56 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> In general, I tried to remove any text from the Permission classes that described behavior if the permissions were granted. So in the above I removed the text because it had words like "protect" and "accessed" and referred to `com.sun.security.jgss.ExtendedGSSContext#inquireSecContext` which no longer does a permission check. I also added the API Note to make it clear the permission could no longer be used to control access.
>> 
>> If there are other Permission classes you think should have their text modified or removed, let me know.
>
> All JGSS permission classes follow the same style:
> 
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.
>  ```
> In `javax.security.auth.kerberos.DelegationPermission`:
> 
>  * This class is used to restrict the usage of the Kerberos
>  * delegation model, ie: forwardable and proxiable tickets.

I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1805188374

From amenkov at openjdk.org  Thu Oct 17 20:31:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 17 Oct 2024 20:31:39 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
Message-ID: <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>

On Thu, 17 Oct 2024 02:33:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review test tweaks: add @bug tag; a reliability update

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 62:

> 60:          jmethodID method, jboolean wasPoppedByException) {
> 61:   jvmtiError err;
> 62:   char* expected_method = (char*)last_notify_method;

I don't think caching `last_notify_method` adds any reliability.
`notifyFramePop` deallocates the memory.

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 87:

> 85:   }
> 86:   deallocate(jvmti, jni, csig);
> 87:   deallocate(jvmti, jni, name);

on error `csig` and `name` are deallocated twice

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 171:

> 169:   } else {
> 170:     char* old_notify_method = (char*)last_notify_method;
> 171:     last_notify_method = name;

I don't think this adds reliability.
Control thread suspends main test thread before call this method. AFAIU suspend cannot complete before FramePop callback is completed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805369268
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805370875
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805388024

From cjplummer at openjdk.org  Thu Oct 17 21:22:23 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 17 Oct 2024 21:22:23 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
Message-ID: <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>

On Thu, 17 Oct 2024 20:27:13 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 test tweaks: add @bug tag; a reliability update
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 171:
> 
>> 169:   } else {
>> 170:     char* old_notify_method = (char*)last_notify_method;
>> 171:     last_notify_method = name;
> 
> I don't think this adds reliability.
> Control thread suspends main test thread before call this method. AFAIU suspend cannot complete before FramePop callback is completed.

Yes, this is all very synchronous. The control thread suspends the thread, we call NotifyFramePop on the thread, the control thread resumes the thread and then waits for confirmation of the FRAME_POP before repeating the process. I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805444716

From wkemper at openjdk.org  Thu Oct 17 21:41:45 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 17 Oct 2024 21:41:45 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <KQqx9s1UaQvKGVdbT7DfqovPsSDciqK-Swy5TTqNc1s=.dda14ecb-8c8a-4089-85fa-cad144b3f533@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
 <KQqx9s1UaQvKGVdbT7DfqovPsSDciqK-Swy5TTqNc1s=.dda14ecb-8c8a-4089-85fa-cad144b3f533@github.com>
Message-ID: <gheaI-FO443qkaR77RLSHuQZHjskTN7JCyY923ewW0k=.007ee5a2-1710-4358-9c18-378cacbc2d77@github.com>

On Fri, 11 Oct 2024 21:21:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 396:
>> 
>>> 394: }
>>> 395: 
>>> 396: inline bool ShenandoahHeap::is_old(oop obj) const {
>> 
>> What is the difference between this method and the above is_in_old()? Why does it need to check that active generation is young?
>
> This is just a bad, confusing method name. I'll fix this.

https://bugs.openjdk.org/browse/JDK-8342560

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1805475522

From amenkov at openjdk.org  Thu Oct 17 21:53:56 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 17 Oct 2024 21:53:56 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
 <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
Message-ID: <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>

On Thu, 17 Oct 2024 21:18:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 171:
>> 
>>> 169:   } else {
>>> 170:     char* old_notify_method = (char*)last_notify_method;
>>> 171:     last_notify_method = name;
>> 
>> I don't think this adds reliability.
>> Control thread suspends main test thread before call this method. AFAIU suspend cannot complete before FramePop callback is completed.
>
> Yes, this is all very synchronous. The control thread suspends the thread, we call NotifyFramePop on the thread, the control thread resumes the thread and then waits for confirmation of the FRAME_POP before repeating the process. I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.

Control thread waits until pop_count is updated and FramePop callback updates it at the beginning, so control thread can start next iteration (i.e. call SuspentThread) before FramePop is completed.
But my understanding that SuspentThread cannot return before FramePop completed, so there is no synchronization issues here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805488341

From cjplummer at openjdk.org  Thu Oct 17 22:01:46 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 17 Oct 2024 22:01:46 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
 <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
 <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>
Message-ID: <MR8ybftMkz7Is5Axo7n2_wIBsvFLvVabGSCxEd2pO7g=.cc505179-d99d-481d-ba8e-634c4419d228@github.com>

On Thu, 17 Oct 2024 21:50:39 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Yes, this is all very synchronous. The control thread suspends the thread, we call NotifyFramePop on the thread, the control thread resumes the thread and then waits for confirmation of the FRAME_POP before repeating the process. I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.
>
> Control thread waits until pop_count is updated and FramePop callback updates it at the beginning, so control thread can start next iteration (i.e. call SuspentThread) before FramePop is completed.
> But my understanding that SuspentThread cannot return before FramePop completed, so there is no synchronization issues here

Actually I'm not so sure of your last statement. I think while in the FramePop callback the thread can do things that allow it to be suspended. So if the control thread has already detected that FramePop callback has been called, it may move on to the next iteration before the FramePop callback completes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805493986

From sspitsyn at openjdk.org  Thu Oct 17 22:50:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 22:50:32 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v6]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <gB9cPG0YeHxVQPGwn9AfHOCe7d7tVD1485hevNF78pA=.a82bda5e-6c7a-4cc7-bdfb-8e2de4311f98@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review: remake the reliability update with a raw monitor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/dc457681..c2eb37d1

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

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

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

From sspitsyn at openjdk.org  Thu Oct 17 22:50:33 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 22:50:33 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
Message-ID: <LeDsDcfkF_R3m_iB9o0nu2ljuaa3_gKxAaeFzaumPKY=.b5a50356-5a64-47b4-a4b8-2217502d6448@github.com>

On Thu, 17 Oct 2024 20:08:44 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 test tweaks: add @bug tag; a reliability update
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 62:
> 
>> 60:          jmethodID method, jboolean wasPoppedByException) {
>> 61:   jvmtiError err;
>> 62:   char* expected_method = (char*)last_notify_method;
> 
> I don't think caching `last_notify_method` adds any reliability.
> `notifyFramePop` deallocates the memory.

Agreed, thanks. Please, see my comment below.

> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 87:
> 
>> 85:   }
>> 86:   deallocate(jvmti, jni, csig);
>> 87:   deallocate(jvmti, jni, name);
> 
> on error `csig` and `name` are deallocated twice

Agreed, thanks. Removed the deallocation on error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805537772
PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805538666

From sspitsyn at openjdk.org  Thu Oct 17 23:11:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 23:11:22 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v7]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <aYmi8q5vOcjFz1g-gsi_kJFXEJLq0eLnM0Bt5AUs4bI=.8da85424-5baa-43f2-a2df-0d714854784c@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  no need in raw monitor - removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/c2eb37d1..9a08d9cc

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

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

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

From sspitsyn at openjdk.org  Thu Oct 17 23:15:55 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 23:15:55 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <MR8ybftMkz7Is5Axo7n2_wIBsvFLvVabGSCxEd2pO7g=.cc505179-d99d-481d-ba8e-634c4419d228@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
 <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
 <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>
 <MR8ybftMkz7Is5Axo7n2_wIBsvFLvVabGSCxEd2pO7g=.cc505179-d99d-481d-ba8e-634c4419d228@github.com>
Message-ID: <brZtQlv8ltrzvQFHFHDUNMw-hbG_6FCJ4-Wfgo8LML0=.7f3dc0d6-3a44-48de-90d7-3a9f02e60906@github.com>

On Thu, 17 Oct 2024 21:58:18 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Control thread waits until pop_count is updated and FramePop callback updates it at the beginning, so control thread can start next iteration (i.e. call SuspentThread) before FramePop is completed.
>> But my understanding that SuspentThread cannot return before FramePop completed, so there is no synchronization issues here
>
> Actually I'm not so sure of your last statement. I think while in the FramePop callback the thread can do things that allow it to be suspended. So if the control thread has already detected that FramePop callback has been called, it may move on to the next iteration before the FramePop callback completes.

Agreed, thanks.
The suspend should happen in the `ThreadInVMfromJava()` destructor that is a part of the `JRT_BLOCK` macro.  I've pushed the fix now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805571025

From cjplummer at openjdk.org  Thu Oct 17 23:21:30 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 17 Oct 2024 23:21:30 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v7]
In-Reply-To: <aYmi8q5vOcjFz1g-gsi_kJFXEJLq0eLnM0Bt5AUs4bI=.8da85424-5baa-43f2-a2df-0d714854784c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <aYmi8q5vOcjFz1g-gsi_kJFXEJLq0eLnM0Bt5AUs4bI=.8da85424-5baa-43f2-a2df-0d714854784c@github.com>
Message-ID: <gZv0bQzWcv50MoRvsllFW191EWrDjzk5ljeuXvvblHY=.10a23f6d-b6c2-4406-8246-fb81ea75f746@github.com>

On Thu, 17 Oct 2024 23:11:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no need in raw monitor - removed

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 66:

> 64:   char* name = nullptr;
> 65: 
> 66:   pop_count++;

I think there is still a concern that once this increment is done, the next iteration in control() can start. It will try to suspend this thread, which I think can happen in the 3 JVMTI calls below, and controll() will then call NotifyFramePop(), which will clobber last_notify_method. I think just moving this increment to the end will resolve that issue, or at least move it to after the last_notify_method reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805577010

From sspitsyn at openjdk.org  Thu Oct 17 23:21:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 23:21:30 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <brZtQlv8ltrzvQFHFHDUNMw-hbG_6FCJ4-Wfgo8LML0=.7f3dc0d6-3a44-48de-90d7-3a9f02e60906@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
 <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
 <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>
 <MR8ybftMkz7Is5Axo7n2_wIBsvFLvVabGSCxEd2pO7g=.cc505179-d99d-481d-ba8e-634c4419d228@github.com>
 <brZtQlv8ltrzvQFHFHDUNMw-hbG_6FCJ4-Wfgo8LML0=.7f3dc0d6-3a44-48de-90d7-3a9f02e60906@github.com>
Message-ID: <go6h93gjKIo7T0GtllHHagRDEC5w4ybhwlYo9fc9C_A=.613dfd3c-9ab7-448a-9774-e6436373f8b2@github.com>

On Thu, 17 Oct 2024 23:11:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Actually I'm not so sure of your last statement. I think while in the FramePop callback the thread can do things that allow it to be suspended. So if the control thread has already detected that FramePop callback has been called, it may move on to the next iteration before the FramePop callback completes.
>
> Agreed, thanks.
> The interesting suspend point is in the `ThreadInVMfromJava()` destructor that is a part of the `JRT_BLOCK` macro.  I've pushed the fix now.

> I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.

The mach5 test runs hit some strange crashes in `deallocate()` and I've made a wrong conclusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805579127

From sspitsyn at openjdk.org  Thu Oct 17 23:28:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 23:28:14 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v7]
In-Reply-To: <gZv0bQzWcv50MoRvsllFW191EWrDjzk5ljeuXvvblHY=.10a23f6d-b6c2-4406-8246-fb81ea75f746@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <aYmi8q5vOcjFz1g-gsi_kJFXEJLq0eLnM0Bt5AUs4bI=.8da85424-5baa-43f2-a2df-0d714854784c@github.com>
 <gZv0bQzWcv50MoRvsllFW191EWrDjzk5ljeuXvvblHY=.10a23f6d-b6c2-4406-8246-fb81ea75f746@github.com>
Message-ID: <2KADrIgSlGHjNjIsQbjPHdF623k3fNF3pF2V7H8TDgM=.2e27d4f7-0e90-4550-88db-1edf1b3f0c6c@github.com>

On Thu, 17 Oct 2024 23:14:50 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   no need in raw monitor - removed
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 66:
> 
>> 64:   char* name = nullptr;
>> 65: 
>> 66:   pop_count++;
> 
> I think there is still a concern that once this increment is done, the next iteration in control() can start. It will try to suspend this thread, which I think can happen in the 3 JVMTI calls below, and controll() will then call NotifyFramePop(), which will clobber last_notify_method. I think just moving this increment to the end will resolve that issue, or at least move it to after the last_notify_method reference.

I agree, it is more safe to move the increment to the end. Moved now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805583958

From sspitsyn at openjdk.org  Thu Oct 17 23:35:44 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 17 Oct 2024 23:35:44 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v5]
In-Reply-To: <go6h93gjKIo7T0GtllHHagRDEC5w4ybhwlYo9fc9C_A=.613dfd3c-9ab7-448a-9774-e6436373f8b2@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <IpIACjz2TXT7p2rzGcz7GfrGV2jQk94J3PvTxDu09ck=.8fc4b899-fcd1-4dd6-99fb-935dbe4f01c6@github.com>
 <sc_OHluX_bkuF8PlPXB__rSYOOp_4hs35xN_7ItoDLE=.1be0208e-3dfd-40d0-bae3-935ce6e1a855@github.com>
 <T2yfvhcukPzSivXSY6Hyr8IGVn3bkZz5Zy4R4SSlOeA=.c3b94fe0-b44f-46de-adb6-1f329c1c4b61@github.com>
 <0mhh437_vpQ86hZPBKWccX7aVh6CZQPaSk4jxSxLBMU=.0ec660aa-6f9b-4900-9c44-9e16cd2d946b@github.com>
 <MR8ybftMkz7Is5Axo7n2_wIBsvFLvVabGSCxEd2pO7g=.cc505179-d99d-481d-ba8e-634c4419d228@github.com>
 <brZtQlv8ltrzvQFHFHDUNMw-hbG_6FCJ4-Wfgo8LML0=.7f3dc0d6-3a44-48de-90d7-3a9f02e60906@github.com>
 <go6h93gjKIo7T0GtllHHagRDEC5w4ybhwlYo9fc9C_A=.613dfd3c-9ab7-448a-9774-e6436373f8b2@github.com>
Message-ID: <8aCXOKQPML-IxA066wHyEd0AxRNACuHdCtyA2y3rifs=.ffa62944-7a4d-40c7-be9c-5b55c249ed94@github.com>

On Thu, 17 Oct 2024 23:17:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Agreed, thanks.
>> The interesting suspend point is in the `ThreadInVMfromJava()` destructor that is a part of the `JRT_BLOCK` macro.  I've pushed the fix now.
>
>> I'm not sure what motivated the change to add old_notify_method. Maybe there was some other issue that was misunderstood.
> 
> The mach5 test runs hit some strange crashes in `deallocate()` and I've made a wrong conclusion.

> So if the control thread has already detected that FramePop callback has been called, it may move on to the next iteration before the FramePop callback completes.

This is important point to understand about the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805589349

From sspitsyn at openjdk.org  Fri Oct 18 00:28:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 00:28:51 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v8]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <eb67Hdjie6V6s9KrrkdM0m8tWsVoNAN1hi511r3n-Gg=.7137f22a-4deb-401e-bf15-b2b6746570bc@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review: move pop_count++ to the end of FramePop handler for more safety

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/9a08d9cc..6895abbd

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

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

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

From cjplummer at openjdk.org  Fri Oct 18 00:43:47 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 18 Oct 2024 00:43:47 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v8]
In-Reply-To: <eb67Hdjie6V6s9KrrkdM0m8tWsVoNAN1hi511r3n-Gg=.7137f22a-4deb-401e-bf15-b2b6746570bc@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <eb67Hdjie6V6s9KrrkdM0m8tWsVoNAN1hi511r3n-Gg=.7137f22a-4deb-401e-bf15-b2b6746570bc@github.com>
Message-ID: <aBWsxvjKOyTb_rxJuUVLS3jJw41dHSr-8Elky7DK25A=.f8bce125-94b9-426c-bb44-31a766abad9b@github.com>

On Fri, 18 Oct 2024 00:28:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: move pop_count++ to the end of FramePop handler for more safety

test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 73:

> 71: 
> 72:   name = get_method_name(jvmti, jni, method);
> 73:   LOG("FramePop(%d) event from method: %s %s\n", pop_count, csig, name);

I just noticed this pop_count reference here. Probably best to change it to pop_count  + 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805661610

From sspitsyn at openjdk.org  Fri Oct 18 00:53:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 00:53:37 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v6]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

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

  review: clarify the use of annotation @JvmtiMountTransition in yield/yield0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/f8d05152..94862c30

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

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

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

From sspitsyn at openjdk.org  Fri Oct 18 01:11:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 01:11:32 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v9]
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

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

  review: minor tweaks in test log and static vars initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21468/files
  - new: https://git.openjdk.org/jdk/pull/21468/files/6895abbd..722fdc33

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

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

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

From sspitsyn at openjdk.org  Fri Oct 18 01:11:32 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 01:11:32 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v8]
In-Reply-To: <aBWsxvjKOyTb_rxJuUVLS3jJw41dHSr-8Elky7DK25A=.f8bce125-94b9-426c-bb44-31a766abad9b@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <eb67Hdjie6V6s9KrrkdM0m8tWsVoNAN1hi511r3n-Gg=.7137f22a-4deb-401e-bf15-b2b6746570bc@github.com>
 <aBWsxvjKOyTb_rxJuUVLS3jJw41dHSr-8Elky7DK25A=.f8bce125-94b9-426c-bb44-31a766abad9b@github.com>
Message-ID: <BJSUx53UWdzZ9byLOE_tcXxgRMMKl1aYdAOVT6mRD7A=.10762332-8a0e-4ed2-9e71-1b98ec10fc54@github.com>

On Fri, 18 Oct 2024 00:40:38 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: move pop_count++ to the end of FramePop handler for more safety
>
> test/hotspot/jtreg/serviceability/jvmti/events/NotifyFramePopStressTest/libNotifyFramePopStressTest.cpp line 73:
> 
>> 71: 
>> 72:   name = get_method_name(jvmti, jni, method);
>> 73:   LOG("FramePop(%d) event from method: %s %s\n", pop_count, csig, name);
> 
> I just noticed this pop_count reference here. Probably best to change it to pop_count  + 1.

Nice catch. Fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21468#discussion_r1805680619

From cjplummer at openjdk.org  Fri Oct 18 01:33:03 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 18 Oct 2024 01:33:03 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v9]
In-Reply-To: <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
Message-ID: <1YTS85cAYTsx2b5DeZc2D9d7kvWebQfRbtchv_HW_mY=.eb2ce1ee-0a71-4002-ba03-b67b8ec27250@github.com>

On Fri, 18 Oct 2024 01:11:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweaks in test log and static vars initialization

Looks good. Thanks for all the updates to the test.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2376723248

From aboldtch at openjdk.org  Fri Oct 18 06:46:22 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 18 Oct 2024 06:46:22 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v4]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas 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 tag 'jdk-24+20' into JDK-8341692
   
   Added tag jdk-24+20 for changeset 7a64fbbb
 - Merge tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - Remove XCollectedHeap from HSDB
 - Fix typo in TestZUncommitEvent.java
 - ... and 3 more: https://git.openjdk.org/jdk/compare/7a64fbbb...76c5d0c6

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

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=03
  Stats: 39433 lines in 406 files changed: 155 ins; 39008 del; 270 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

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

From stefank at openjdk.org  Fri Oct 18 07:24:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 18 Oct 2024 07:24:40 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v4]
In-Reply-To: <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <0wC3rZqgWGF5Pyjs9yfUPEXpkU_Q-uYE1gUth7jGfew=.ee3e19a3-3951-4cde-ac19-b8a0b089508b@github.com>
Message-ID: <-V8KgQ0UJkawIutURV9UhV1kmb8Yh4oDumTryF069cA=.0be23393-ced1-4c14-9113-bf1a819b1d9a@github.com>

On Fri, 18 Oct 2024 06:46:22 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas 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 tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - Remove XCollectedHeap from HSDB
>  - Fix typo in TestZUncommitEvent.java
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7a64fbbb...76c5d0c6

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2377217619

From alanb at openjdk.org  Fri Oct 18 07:57:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 18 Oct 2024 07:57:05 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v6]
In-Reply-To: <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <lTyFI-rG1EircImARu90iJW5vTmbs-pBkboLoVSx4Ok=.b388e925-385b-4e8d-b10b-0586725bd5d2@github.com>
Message-ID: <yytrrZQvNLLvLMUC4lZPTjhn8ExroM56uRT9_TFctOI=.a9247b9a-9d05-47d3-9691-eb37753cb5b2@github.com>

On Fri, 18 Oct 2024 00:53:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: clarify the use of annotation @JvmtiMountTransition in yield/yield0

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 35:

> 33:  * The Continuation yield and yield0 frames normally are in VTMS transition
> 34:  * but can be found out of transition in an unmounted virtual thread.
> 35:  * This inconsistency is the reason why they also need this annotation.

In ChangesCurrentThread, Hidden and the other annotations, the description explains where they must be used. The JvmtiMountTransition description isn't very clear as it's explain why the Continuation yield methods need the annotation. It's okay if the description is re-worked in some future PR, my comment is just that the current description is very confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1806047399

From amenkov at openjdk.org  Fri Oct 18 18:18:53 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 18 Oct 2024 18:18:53 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v9]
In-Reply-To: <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
Message-ID: <hfqN3zR4_R8f5hyazyzwPcbML_TeYZkF1eq7MfWdQoY=.c0ee3931-e47b-4734-a372-e3a89989b650@github.com>

On Fri, 18 Oct 2024 01:11:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweaks in test log and static vars initialization

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21468#pullrequestreview-2378712908

From wkemper at openjdk.org  Fri Oct 18 18:21:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 18 Oct 2024 18:21:33 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
Message-ID: <K3hhDTHhqdR_JM1PPMAx9lKjLU35BPoMPHBA0OVpvtw=.096eea95-ccd3-4b4f-b925-0875f76db658@github.com>

> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 487 commits:

 - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
 - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
   
   Reviewed-by: kdnilsen, ysr
 - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
   
   Reviewed-by: ysr
 - 8342278: GenShen: Move non-generational mode test out of generational test configuration
   
   Reviewed-by: ysr
 - 8342255: GenShen: Remove unnecessary enum initial values
   
   Reviewed-by: ysr
 - 8342001: GenShen: Factor cases for allocation type into separate methods
   
   Reviewed-by: ysr, kdnilsen
 - 8341992: GenShen:  Fix formatting, remove unreachable code, unused imports and unnecessary comments
   
   Reviewed-by: ysr
 - Merge
 - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
 - Fix merge error
 - ... and 477 more: https://git.openjdk.org/jdk/compare/3da68900...b3e4b4ca

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

Changes: https://git.openjdk.org/jdk/pull/21273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=03
  Stats: 22819 lines in 229 files changed: 21077 ins; 890 del; 852 mod
  Patch: https://git.openjdk.org/jdk/pull/21273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273

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

From sspitsyn at openjdk.org  Fri Oct 18 18:29:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 18:29:40 GMT
Subject: RFR: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning [v9]
In-Reply-To: <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
 <-_5H_mHfXeNGTBcdEigKzA50yEkO4kLrtKO1rhLNySE=.ef621c7a-37b2-4b36-897b-7a8ca486e655@github.com>
Message-ID: <RYTh8gdGIbCOpyGBlAZ6GHGVY1qQIYTcSCMIUoXWLvM=.3765d222-9a01-48a1-b1b5-87c33d196720@github.com>

On Fri, 18 Oct 2024 01:11:32 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
>> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
>> 
>> Testing:
>>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>>  - TBD: mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweaks in test log and static vars initialization

Chris and Alex, thank you for review!

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

PR Comment: https://git.openjdk.org/jdk/pull/21468#issuecomment-2423012469

From mullan at openjdk.org  Fri Oct 18 19:03:30 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:03:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
 - Sanitize the class descriptions of DelegationPermission and ServicePermission
   by removing text that refers to granting permissions, but avoid changes that
   affect the API specification, such as the description and format of input
   parameters.
 - Restored methods in RMIConnection to throw SecurityExceptions again but
   with adjusted text that avoids the word "permission".
 - Add text to class description of MBeanServer stating that implementations
   may throw SecurityException if authorization doesn't allow access to resource.
 - Restore text about needing permissions from the desktop environment in the
   getPixelColor and createScreenCapture methods.
 - Add api note to getClassContext to use StackWalker instead and
   add DROP_METHOD_INFO option to StackWalker.
 - Change checkAccess() methods to be no-ops, rather than throwing
   SecurityException.
 - Merge
 - Merge
 - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=01
  Stats: 63792 lines in 1825 files changed: 932 ins; 59211 del; 3649 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From sspitsyn at openjdk.org  Fri Oct 18 19:38:09 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 18 Oct 2024 19:38:09 GMT
Subject: Integrated: 8340698: JVMTI FRAME_POP event is sometimes missed if
 NotifyFramePop is called as a method is returning
In-Reply-To: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
References: <V-CbGkqDkHL0YuQjRGoX6gRpwT5FytYbiZp2HuSAuyM=.3f10c622-2e3e-4b2c-99d5-eba9cce5b47c@github.com>
Message-ID: <lzId1OkzuKGZ1CV99wxmuQIZKEdL_oY7yiQAgnCnCq0=.550724c2-926c-4a1c-997a-d9433f36817c@github.com>

On Fri, 11 Oct 2024 08:39:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> There is a race between JVMTI NotifyFramePop function and FramePop event posting code.
> The fix is to return JVMTI_ERROR_OPAQUE_FRAME if if a FramePop event with depth 0 is requested by NotifyFramePop at the time when the target frame is in exit epilogue, and MethodExit/FramePop events are being posted for it.
> 
> Testing:
>  - verified locally with new test (developed by Chris): `serviceability/jvmti/events/NotifyFramePopStressTest`
>  - TBD: mach5 tiers 1-6

This pull request has now been integrated.

Changeset: 85911094
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8591109419efc8f71544a98bdb04a48cb1afc47e
Stats:     340 lines in 6 files changed: 339 ins; 0 del; 1 mod

8340698: JVMTI FRAME_POP event is sometimes missed if NotifyFramePop is called as a method is returning

Reviewed-by: cjplummer, amenkov

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

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

From pchilanomate at openjdk.org  Fri Oct 18 19:41:27 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads without
 Pinning
Message-ID: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>

This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.

In order to make the code review easier the changes have been split into the following initial 4 commits:

- Changes to allow unmounting a virtual thread that is currently holding monitors.
- Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
- Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
- Changes to tests, JFR pinned event, and other changes in the JDK libraries.

The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.

The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.


## Summary of changes

### Unmount virtual thread while holding monitors

As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:

- We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

- For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.

#### General notes about this part:

- Since virtual threads don't need to worry about holding monitors anymore, we don't need to count them, except for `LM_LEGACY`. So the majority of the platform dependent changes in this commit have to do with correcting this.
- Zero and x86 (32 bits) where counting monitors even though they don't implement continuations, so I fixed that to stop counting. The idea is to remove all the counting code once we remove `LM_LEGACY`.
- Macro `LOOM_MONITOR_SUPPORT` was added at the time to exclude ports that implement continuations but don't yet implement monitor support. It is removed later with the ppc commit changes.
- Since now a virtual thread can be unmounted while holding monitors, JVMTI methods `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` had to be adapted.

#### Notes specific to the tid changes:

- The tid is cached in the JavaThread object under `_lock_id`. It is set on JavaThread creation and changed on mount/unmount.
- Changes in the ObjectMonitor class in this commit are pretty much exclusively related to changing `_owner` and `_succ` from `void*` and `JavaThread*` respectively to `int64_t`.
- Although we are not trying to fix `LM_LEGACY` the tid changes apply to it as well since the inflated path is shared. Thus, in case of inflation by a contending thread, the `BasicLock*` cannot be stored in the `_owner` field as before. The `_owner` is instead set to anonymous as we do in `LM_LIGHTWEIGHT`, and the `BasicLock*` is stored in the new field `_stack_locker`.
- We already assume 32 bit platforms can handle 64 bit atomics, including `cmpxchg` ([JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776)) so the shared code can stay the same. The assembly code for the c2 fast paths has to be adapted though. On arm (32bits) we already jump directly to the slow path on inflated monitor case so there is nothing to do. For x86 (32bits), since the port is moving towards deprecation ([JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285)) there is no point in trying to optimize, so the code was changed to do the same thing we do for arm (32bits).

### Unmounting a virtual thread blocked on synchronized

Currently virtual thread unmounting is always started from Java, either because of a voluntarily call to `Thread.yield()` or because of performing some blocking operation such as I/O. Now we allow to unmount from inside the VM too, specifically when facing contention trying to acquire a Java monitor.

On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. Once the owner releases the monitor and selects it as the next successor the virtual thread will be added again to the scheduler queue to run again. The virtual thread will run and attempt to acquire the monitor again. If it succeeds then it will thaw frames as usual to continue execution back were it left off. If it fails it will unmount and wait again to be unblocked.

#### General notes about this part:

- The easiest way to review these changes is to start from the monitorenter call in the interpreter and follow all the flow of the virtual thread, from unmounting to running again.
- Currently we use a dedicated unblocker thread to submit the virtual threads back to the scheduler queue. This avoids calls to Java from monitorexit. We are experimenting on removing this limitation, but that will be left as an enhancement for a future change.
- We cannot unmount the virtual thread when the monitor enter call is coming from `jni_enter()` or `ObjectLocker` since we would need to freeze native frames.
- If freezing fails, which almost always will be due to having native frames on the stack, the virtual thread will follow the normal platform thread logic but will do a timed-park instead. This is to alleviate some deadlocks cases where the successor picked is an unmounted virtual thread that cannot run, which can happen during class loading or class initiatialization.
- After freezing all frames, and while adding itself to the `_cxq` the virtual thread could?have successfully acquired the monitor. In that case we mark the preemption as cancelled. The virtual thread will still need to go back to the preempt stub to cleanup the physical stack but instead of unmounting it will call thaw to continue execution.
- The way we jump to the preempt stub is slightly different in the compiler and interpreter. For the compiled case we just patch a return address, so no new code is added. For the interpreter we cannot do this on all platforms so we just check a flag back in the interpreter. For the latter we also need to manually restore some state after we finally acquire the monitor and resume execution. All that logic is contained in new assembler method `call_VM_preemptable()`.

#### Notes specific to JVMTI changes:
- Since we are not unmounting from Java, there is no call to `VirtualThread.yieldContinuation()`. This means that we have to execute the equivalent of `notifyJvmtiUnmount(/*hide*/true)` for unmount, and of `notifyJvmtiMount(/*hide*/false)` for mount in the VM. The former is implemented with `JvmtiUnmountBeginMark` in `Continuation::try_preempt()`. The latter is implemented in method `jvmti_mount_end()` in `ContinuationFreezeThaw` at the end of thaw.
- When unmounting from Java the vthread unmount event is posted before we try to freeze the continuation. If that fails then we post the mount event. This all happens in `VirtualThread.yieldContinuation()`. When unmounting from the VM we only post the event once we know the freeze succeeded. Since at that point we are in the middle of the VTMS transition, posting the event is done in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()` after the transition finishes. Maybe the same thing should be done when unmounting from Java.

### Unmounting a virtual thread blocked on `Object.wait()`

This commit just extends the previous mechanism to be able to unmount inside the VM on `ObjectMonitor::wait`.

####  General notes about this part:
- The mechanism works as before with the difference that now the call will come from the native wrapper. This requires to add support to the continuation code to handle native wrapper frames, which is a main part of the changes in this commit.
- Both the compiled and interpreted native wrapper code will check for preemption on return from the wait call, after we have transitioned back to `_thread_in_Java`.

####  Note specific to JVMTI changes:
- If the monitor waited event is enabled we need to post it after the wait is done but before re-acquiring the monitor. Since the virtual thread is inside the VTMS transition at that point, we cannot do that directly. Currently in the code we end the transition, post the event and start the transition again. This is not ideal, and maybe we should unmount, post the event and then run again to try reacquire the monitor.


### Test changes + JFR Updates + Library code changes

#### Tests 

- The tests in `java/lang/Thread/virtual` are updated to add more tests for monitor enter/exit and Object.wait/notify. New tests are added for JFR events, synchronized native methods, and stress testing for several scenarios.
- `test/hotspot/gtest/nmt/test_vmatree.cpp` is changed due to an alias that conflicts. 
- A small number of tests, e.g.` test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`, are updated so they are in sync with the JDK code. 
- A number of JVMTI tests are updated to fix various issues, e.g. some tests saved a JNIEnv in a static. 

#### Diagnosing remaining pinning issues

- The diagnostic option `jdk.tracePinnedThreads` is removed. 
- The JFR `jdk.VirtualThreadPinned` event is changed so that it's now recorded in the VM, and for the following cases: parking when pinned, blocking in monitor enter when pinned, Object.wait when pinned, and waiting for a class to be initialized by another thread. The changes to object monitors should mean that only a few events are recorded. Future work may change this to a sampling approach.

#### Other changes to VirtualThread class

The VirtualThread implementation includes a few robustness changes. The `park/parkNanos` methods now park on the carrier if the freeze throws OOME. Moreover, the use of transitions is reduced so that the call out to the scheduler no longer requires a temporary transition. 

#### Other changes to libraries: 

- `ReferenceQueue` is reverted to use `synchronized`, the subclass based on `ReentrantLock` is removed. This change is done now because the changes for object monitors impact this area when there is preemption polling a reference queue. 
- `java.io` is reverted to use `synchronized`. This change has been important for testing virtual threads. There will be follow-up cleanup in main-line after the JEP is integrated to remove `InternalLock` and its uses in `java.io`. 
- The epoll and kqueue based Selectors are changed to preempt when doing blocking selects. This has been useful for testing virtual threads with some libraries, e.g. JDBC drivers. We could potentially separate this update if needed but it has been included in all testing and EA builds. 
- `sun.security.ssl.X509TrustManagerImpl` is changed to eagerly initialize AnchorCertificates, a forced change due to deadlocks in this code when testing. 

## Testing 

The changes have been running in the Loom pipeline for several months now. They have also been included in EA builds throughout the year at different stages (EA builds from earlier this year did not had Object.wait() support yet but more recent ones did) so there has been some external exposure too.

The current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time.

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

Commit messages:
 - Add PPC64 support
 - Test changes + JFR Updates + Library code changes
 - Allow virtual threads to unmount when blocked on Object.wait()
 - Allow virtual threads to unmount when blocked on synchronized
 - Allow virtual threads to unmount while holding monitors

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338383
  Stats: 9459 lines in 242 files changed: 6942 ins; 1400 del; 1117 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From dholmes at openjdk.org  Fri Oct 18 19:41:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

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

> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporal value.

Suggestion:

  // attached thread cases where this field can have a temporary value.

Presumably this is for when the attaching thread is executing the Thread constructor?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004

From pchilanomate at openjdk.org  Fri Oct 18 19:41:28 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 18 Oct 2024 19:41:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
Message-ID: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>

On Fri, 18 Oct 2024 00:09:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/javaThread.hpp line 165:
> 
>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporal value.
> 
> Suggestion:
> 
>   // attached thread cases where this field can have a temporary value.
> 
> Presumably this is for when the attaching thread is executing the Thread constructor?

Exactly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255

From mullan at openjdk.org  Fri Oct 18 19:46:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <XkYomUCuYPfv4w1a6Ow341czNQk0BZtVYQ5siKARaCw=.f9903208-986b-49ec-9b2b-0f9f3420b8e0@github.com>
 <x7V0xkjtIVjHzg759KRouiOSebSTC-2qtHhLMUg_ix8=.f0b9b82d-5b95-4510-ae63-1cd02459538b@github.com>
 <tPGJm_oDetggeMw0Y8u7883A5h59TmEG9L23VaMdQY4=.be8a794c-6988-4cc4-8507-924987023aa8@github.com>
 <YL7b7TrzbtabBUtS_uu_tpp99WTMxfwSdL76aCXMA00=.8d4680e4-8e23-484b-a079-4417eaa1a10c@github.com>
 <uKlE5Z_DB5hGTKhAJS8g2J4gxfQaGxCnXvWxfgQnlRQ=.cdfc9c67-324a-4a15-a44b-ace997385449@github.com>
 <1Xk9_Kdo4soB1blDFYc7dL29K5w4Vzj5TFyICKG9Ryw=.bb2b91df-3119-47a4-a6e6-c52d9aa27190@github.com>
 <2YtkErzuokjAVm0p8GOt4-nAmWQt2vNo6WU70ObWcZo=.41863526-1125-452f-aed0-44daccb7fead@github.com>
Message-ID: <WQXBnhvSCgaSLXJytauYL7d7V9avIZVl75sej33nL0o=.82c6cfc9-a4fd-4b44-84f1-0a268a501d04@github.com>

On Thu, 17 Oct 2024 05:54:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ok, I'll also add an API note to `getClassContext()` to use `StackWalker` instead.
>
> Okay, it already has `@see StackWalker`. My guess is that anything extending SM to call getClassContext is very old code. If that old code is compiled with JDK 17+ then they should get a warning. In any case, we replaced the implementation to use StackWalker so getClassContext will continue to work until the SM class is removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/7ea65a6febd18ad8f8fa99cfbb8687e761558594

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806946629

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DON1gWP5b5IKlsc9EX_mvXfCet3imzBUDLtaZfvDuG0=.d1d95049-3f02-40ee-b789-6a16336f43ca@github.com>
 <UdI_PfL3AGPcwx9V2w2KUrMP-lqjxbdiy3ns-LK9jSo=.55c6f31e-917c-4f79-80ab-14f3466c2939@github.com>
 <TZEZCS-7s1pDVNQwq9xmW__BjPRvdnymiBjy2iKoEPQ=.3288aeb2-1850-4a44-966b-dc4963816c8c@github.com>
 <BQgN_5WNCM2jvYWXXZ1372A58UHgeOus9o-a1_paVrY=.79bd64cb-9487-43bb-87e7-81cdf7aba483@github.com>
Message-ID: <uqSjjeE7SYkvbhHNrZhbu1LjbFxWuU7ZJDWMAjWf_g0=.801e961d-5085-48d8-9bff-0029b1459e94@github.com>

On Wed, 16 Oct 2024 20:42:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The description for the SecurityException thrown by these methods were adjusted to "if access to the screen is denied by desktop environment". If you bring back the paragraphs that were removed then you might have to adjust the wording a bit as otherwise the word "permissions" is ambiguous.
>
> Phil, if you have better wording for the `@throws SecurityException` of these methods, let me know; otherwise I will restore the paragraph above and below and keep the current text for `SecurityException` the same as it is now.

I restored the text in https://github.com/openjdk/jdk/pull/21498/commits/adf5ed789b0437fa57c87f29e6a4e6b6f7f0c92b. I've left the `@throws SecurityException` text the same, but let me know if you want that changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806948352

From mullan at openjdk.org  Fri Oct 18 19:46:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:46:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <NRY0xGUN_g3Q5E_fj53HdQDEhIDOB7ptZbvWHEty5nk=.3e34c77b-298e-44cf-9c2b-cba0b167bab3@github.com>
 <cE6ej6U3bnsDMZ42s1Jt11TilV9RY36Z0BwjZqEfbp8=.0674c410-45ae-476d-989d-123785d18105@github.com>
 <afG9TfW3BBEoNmkT8SSBa6Osik9AddvR6fbHQyqU1i4=.752c5ff3-c356-46cd-a08b-59d79639aa10@github.com>
 <sDXTTgphujzWsm615hIZQeE_8o5GOFiHXsgZYhjbfqA=.0ad23c3e-b388-4670-aa5a-f21c3b39bdbe@github.com>
 <LfCVv6-ZhP3bEgMSSp7gf2Utwu5VHFQHNY-dci2uYt4=.185b59ec-db12-42f8-b7bb-a17b4e983fd2@github.com>
 <r3vz9QHW09xYim6XaR7CcrgsYwC-heoPql83uVnxgro=.56f19480-583d-487f-8b0e-29aa758cd131@github.com>
Message-ID: <YpVEi_vehntFxBVQBqfYUlJsU5xAAEphz2giQrbbHeQ=.3094111c-c59c-45b2-a13e-140c8b3d6ad3@github.com>

On Tue, 15 Oct 2024 17:01:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>>> While making `LogManager.checkAccess` be a no-op might be more convenient, it could unconditionally permit operations that formerly required a permission check: clearly a bad idea. Always throwing a `SecurityException` is the safest option.
>> 
>> It's not about convenience _or_ safety; this part of the change has a provably flawed logical basis.
>> 
>> These methods would no longer called from within the JDK after this change. All three of these methods were already previously defined to be a no-op when no security manager was installed (specifically when `System.getSecurityManager() == null`). Since no security manager may be installed after this change, this method will always return `null`. Thus, a no-op is still the most correct behavior and does not permit any operation that previously required a permission check (since it was already a no-op any time no security manager was installed, which will now be the only possible scenario). Therefore it is provably no safer to throw `SecurityException` here, since this will only prompt library developers to introduce the workaround I posted above when their tests fail, yielding the exact same result (except with a minor inconvenience to library developers).
>> 
>> Either way is fine (as I said, the workaround is trivial), but IMO it's best to be conscious of the correct reasoning lest flawed assumptions _do_ end up enabling the introduction of unsafe changes elsewhere in the code. We don't have to make any assumptions about safety or previous behavior because it's all statically provable.
>
> I see your point now. We have strived to preserve compatibility with libraries that follow well known code patterns as described in the JEP, so I will discuss this with others who are more familiar with the compatibility risk of making this change.

I have changed `LogManager.checkAccess`, `Thread.checkAccess`, `ThreadGroup.checkAccess` to always do nothing. See the fixes in https://github.com/openjdk/jdk/pull/21498/commits/2ebb6de50194770658462507cee28b785fb30dbd and https://github.com/openjdk/jdk/pull/21498/commits/16e17b89b3dbce4f49706c032c315977dd54c315.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806950866

From mullan at openjdk.org  Fri Oct 18 19:56:17 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
Message-ID: <W8LF9xitgnrJ0GXvQ2clisM9wQDS32sfJ_1w3xFvbTo=.5391529e-f6b5-40fd-a829-9803c0fdb206@github.com>

On Tue, 15 Oct 2024 14:50:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnection.java line 159:
> 
>> 157:      * is specified for the MBean.
>> 158:      * @throws IOException if a general communication exception occurred.
>> 159:      * @throws UnsupportedOperationException if {@code delegationSubject} is non-null.
> 
> Maybe we should revert those changes, or word them differently. AFAIU, is is still possible for a JMXConnectorServer to implement coarse grained authorization by setting up an `MBeanServerAccessController`, and in fact, the default JMX Agent does that. The JDK has a built-in implementation of `MBeanServerAccessController`,  `MBeanServerFileAccessController`, which will throw `SecurityException` if access is denied by the `MBeanServerFileAccessController`. I believe this will result in the `RMIConnection` throwing `SecurityException` if the operation is denied by the `MBeanServerAccessController`.
> 
> So I believe - in all methods here and in `RMIConnectionImpl`, we should leave the door open for `SecurityException` to get thrown.
> 
> An alternative could be to cover that use case with a blanket statement, here, in `RMIConnectionImpl`, in `MBeanServer`, and in `MBeanServerConnection`.

I restored the changes to `RMIConnection` to throw `SecurityException` but adjusted the text to say "is not authorized" instead of "does not have permission". See https://github.com/openjdk/jdk/pull/21498/commits/86ff71461ef1d695c02497626facda63c496a287.

As we discussed offline, I also added a sentence to the `MBeanServer` class description to state that it and its subclasses may throw `SecurityException`s if the implementation doesn't authorize access to the underlying resource: https://github.com/openjdk/jdk/pull/21498/commits/44432e56a91a992150ee873e81282d1fe21e69ea.

> src/java.management/share/classes/javax/management/remote/JMXAuthenticator.java line 67:
> 
>> 65:      */
>> 66:     public Subject authenticate(Object credentials);
>> 67: }
> 
> Should this be reverted? Authentication has not been removed.

Yes. See the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806952922
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953524

From mullan at openjdk.org  Fri Oct 18 19:56:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <SZAz4jsz7oQ8EiXsAiu3PY_s3zBkXaZgpzqEH38ESm8=.7af40133-5eac-4fa6-b3aa-a969186224d7@github.com>
Message-ID: <hOWAuNpI0Pigr9zYPACJJ68_-Q6uBQZuDWDD322bfg8=.ffe44b98-01a9-4125-90dc-318e48fc87b1@github.com>

On Tue, 15 Oct 2024 22:14:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 225:
>> 
>>> 223:      */
>>> 224:     public static JMXConnector connect(JMXServiceURL serviceURL)
>>> 225:             throws IOException {
>> 
>> I wonder if these changes should also be reverted, on the ground that a server may have authentication in place and may refuse the connection. Same below.
>
> Yes, good catches, I will revert some of these JMX methods that can also throw SecurityExceptions for non-SM reasons.

Yes, see the fix in https://github.com/openjdk/jdk/pull/21498/commits/23a43e0d90aff8754909785f582ba0666046cf6c.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806953911

From mullan at openjdk.org  Fri Oct 18 19:56:19 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 18 Oct 2024 19:56:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
Message-ID: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>

On Thu, 17 Oct 2024 17:59:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> All JGSS permission classes follow the same style:
>> 
>> In `javax.security.auth.kerberos.DelegationPermission`:
>> 
>>  * This class is used to restrict the usage of the Kerberos
>>  * delegation model, ie: forwardable and proxiable tickets.
>>  ```
>> In `javax.security.auth.kerberos.ServicePermission`:
>> 
>>  * This class is used to protect Kerberos services and the
>>  * credentials necessary to access those services. There is a one to
>> 
>> (Updated)
>
> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.

See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1806957907

From duke at openjdk.org  Fri Oct 18 20:16:43 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 18 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <V9F38E82rWG3ydtcBhl-buCMyD8G8VnLPMZtODTvpC0=.d084324c-f851-4bb6-98f5-a392e65baa24@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Marked as reviewed by dmlloyd at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2378900585

From duke at openjdk.org  Fri Oct 18 20:43:43 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 18 Oct 2024 20:43:43 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <R_WaDca9nkuBz7qbRVCynovFC2dFyeHnY62Nbkqqd9A=.668f1165-4c34-4beb-9b95-33808d52ed74@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <R_WaDca9nkuBz7qbRVCynovFC2dFyeHnY62Nbkqqd9A=.668f1165-4c34-4beb-9b95-33808d52ed74@github.com>
Message-ID: <xePze37zRdY_uWOCcrTFQMkjMzFfvwyn7TR1r6Uw5Xs=.e3967d37-d451-448f-a166-d9c15dfe0166@github.com>

On Sat, 12 Oct 2024 18:42:34 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> 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>
>
> Just an important test or comparison is needed here. Do you have any comparison of  the performance before and after this PR change set? Even if no degrading is expected, better to test it.

Hi @afshin-zafari!  I haven't compared the performance yet. I can try to look into this next week. But I don't think there should be any difference because we've only switched out the lock. Maybe there would even be an improvement because the lock is less coarse (but probably not much difference since it's only locking around virtual memory, not mallocs).

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

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2423201201

From kevinw at openjdk.org  Fri Oct 18 20:54:30 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 18 Oct 2024 20:54:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <AlbXwhSqJ6KlhPzDu_C7N1p84ZxgYsYImht8GW56D4k=.0283a056-f5ee-4650-b8c9-0df0aaee1797@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for updating the wording on the JMX/management classes, looks good.

src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java
No longer has any changes other than (C), so that should be reverted also. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423214468

From jbechberger at openjdk.org  Fri Oct 18 23:41:31 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 18 Oct 2024 23:41:31 GMT
Subject: Integrated: 8336401: Remove the option onjcmd from the jdwp agent
In-Reply-To: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
References: <HUMo30S8N9WX8JOQdn5rrgvl7Z2rKR-IXXfR5mjpz10=.ae3baf5e-705f-443e-9226-399d0a58374f@github.com>
Message-ID: <WCASmdf9YszUKYMSN2LrNa3JfZX7JA3D2h9_FOF61oc=.5e6ee007-0715-4a4f-aae8-0e824e29def7@github.com>

On Mon, 7 Oct 2024 11:47:12 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Remove the support for on-demand debugging via the onjcmd option.

This pull request has now been integrated.

Changeset: 309b9291
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/309b929147e7dddfa27879ff31b1eaad271def85
Stats:     241 lines in 5 files changed: 0 ins; 239 del; 2 mod

8336401: Remove the option onjcmd from the jdwp agent

Reviewed-by: cjplummer, mbaesken

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

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

From alanb at openjdk.org  Sat Oct 19 11:56:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 19 Oct 2024 11:56:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2423661302

From syan at openjdk.org  Sun Oct 20 02:17:13 2024
From: syan at openjdk.org (SendaoYan)
Date: Sun, 20 Oct 2024 02:17:13 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY
Message-ID: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>

Hi all,
In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.

So the below test command will print error:

make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"


Building target 'test' in configuration 'linux-x86_64-server-release'
JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
RunTests.gmk:206: *** Cannot continue. Stop.


So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.

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

Commit messages:
 - 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be TEST_THREAD_FACTORY

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

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

From stefank at openjdk.org  Mon Oct 21 07:49:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 07:49:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <GuER3Aj4WpJqyLXvCAolRt63PdXIQv-x6Q7V4wKc2iM=.1754df87-fcb5-4734-b181-288ce1f5b9b1@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

The following test crashes `java/lang/StringBuffer/ECoreIndexOf.java#id1` when running with -XX:+UseCompactObjectHeaders.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2425878646

From aturbanov at openjdk.org  Mon Oct 21 08:05:12 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Oct 2024 08:05:12 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:

> 321:             var started2 = new AtomicBoolean();
> 322: 
> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {

Suggestion:

            Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808287799

From aturbanov at openjdk.org  Mon Oct 21 08:36:10 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 21 Oct 2024 08:36:10 GMT
Subject: RFR: 8341927: Remove hardcoded SunJCE provider
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <pHTMCxFXcVLAujVCuaeoJ-6yeM9RXz3IB5STQpVpk4E=.6b475801-1f41-48e3-be06-036c86b1c861@github.com>

On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

test/jdk/javax/security/auth/login/Configuration/GetInstance.java line 88:

> 86:         // get an instance of JavaLoginConfig from SUN
> 87:         Configuration c = Configuration.getInstance(JAVA_CONFIG, null,
> 88:                 System.getProperty("test.provider.name","SUN"));

Suggestion:

                System.getProperty("test.provider.name", "SUN"));

test/jdk/javax/security/auth/login/Configuration/GetInstance.java line 94:

> 92:         try {
> 93:             c = Configuration.getInstance(JAVA_CONFIG, null,
> 94:                     System.getProperty("test.provider.name","SunRsaSign"));

Suggestion:

                    System.getProperty("test.provider.name", "SunRsaSign"));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1808334456
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1808334626

From kevinw at openjdk.org  Mon Oct 21 09:28:44 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 21 Oct 2024 09:28:44 GMT
Subject: RFR: 8342633: javax/management/security/HashedPasswordFileTest.java
 creates tmp file in src dir
Message-ID: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>

Test update: HashedPasswordFileTest.java was using System.getProperty("test.src") as a place to _create_ a file.

jtreg gives us the current working directory for the test invocation as a scratch directory.  Create files there, without reading any property to find another location.

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

Commit messages:
 - 8342633: javax/management/security/HashedPasswordFileTest.java creates tmp file in src dir

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

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

From stuefe at openjdk.org  Mon Oct 21 12:21:17 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 21 Oct 2024 12:21:17 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v23]
In-Reply-To: <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <0BrAbBTKmpqTGDrc--2znzO8t07yoqabwa6g2K05GHI=.d3c17fd5-4770-4623-8d2f-604816afc033@github.com>
 <VjSp2vvwfzZWKtreZyiwjxsSblAX5JHCpF3c0mcYUHs=.b154b3dd-a8f2-4fdf-8176-52709f906891@github.com>
Message-ID: <7CtwplIs-ILCZhSpPwPtZr-GPCd_XxtOnYwku9zIQTY=.8d8a96e1-9627-4da6-ae57-b692e0580598@github.com>

On Fri, 20 Sep 2024 17:46:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'lilliput/JEP-450-temporary-fix-branch-2' into JDK-8305895-v4
>>  - review feedback
>
> src/hotspot/share/memory/metaspace.cpp line 799:
> 
>> 797: 
>> 798:     // Set up compressed class pointer encoding.
>> 799:     // In CDS=off mode, we give the JVM some leeway to choose a favorable base/shift combination.
> 
> I don't know why this comment is here.  Seems out of place.

Its not, but maybe too vague.

There are two ways to initialize CompressedKlassPointers :

- `CompressedKlassPointers::initialize(address, size)` - called here - is used for no CDS case and allows the JVM to freely pick encoding base and shift.
- `CompressedKlassPointers::initialize_for_given_encoding` is called when encoding base and shift are predetermined (when using CDS). Then, the JVM has no freedom at all, it just does sanity checks.

The comment basically says "since here we are not using CDS, we are calling CompressedKlassPointers::initialize(address, size) to give the JVM some freedom when choosing encoding base and shift".

Is this clearer? Should I just remove the code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1808683312

From mullan at openjdk.org  Mon Oct 21 12:44:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Oct 2024 12:44:12 GMT
Subject: RFR: 8341927: Remove hardcoded SunJCE provider
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <tsQFFsOeIO3fQUtFhh7SY32K7733l5T7TQ55fHtYnYg=.29a33f82-3210-47a3-b092-9bfc28392ba9@github.com>

On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

You are changing more than SunJCE providers, so the title of this bug should not be specific to SunJCE. Suggest: "Replace hardcoded security providers with new test.provider.name system property".

Are there any cases where a test has more than one hardcoded provider?

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

PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2426563352

From stuefe at openjdk.org  Mon Oct 21 12:53:13 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 21 Oct 2024 12:53:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v44]
In-Reply-To: <cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <logRSsOv-ZbKrosBAddqiXOOAcr-tMODEDmGksY6uJs=.ee83f2c3-2b57-41f5-b9f4-9b36811ced37@github.com>
 <cQ6B7ZfZdJrEd_dsmQouGG3i45UcX_e_5f1K7fdvTuI=.82c67fe3-671a-4b1e-bfb1-979e65d56b19@github.com>
Message-ID: <rNbxLonojk0uB0Tg01JpxevDvOxQMG45LludjywTzNU=.3d69f1a5-38cb-441c-90ba-0b027e6bd46e@github.com>

On Wed, 16 Oct 2024 15:37:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Problem-list SharedBaseAddress tests on aarch64
>
> src/hotspot/share/oops/compressedKlass.cpp line 185:
> 
>> 183: #endif
>> 184: 
>> 185:   DEBUG_ONLY(sanity_check_after_initialization();)
> 
> This is here twice.

sanity_check_after_initialization is called from both initialization routines, but we only call either one or the other.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1808735324

From erikj at openjdk.org  Mon Oct 21 12:53:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Oct 2024 12:53:54 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY
In-Reply-To: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
Message-ID: <idXSvCe8Cs2BcilNzt3MD_7v20mwawBLKv9OhoMuQY8=.a12a4bf8-3463-4feb-ba75-3a4b7fa342bc@github.com>

On Sun, 20 Oct 2024 02:11:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
> 
> So the below test command will print error:
> 
> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
> 
> 
> Building target 'test' in configuration 'linux-x86_64-server-release'
> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
> RunTests.gmk:206: *** Cannot continue. Stop.
> 
> 
> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 66:

> 64:         // Virtual threads are not supported by GetObjectMonitorUsage.
> 65:         // Correct the expected values if the test is executed with
> 66:         // TEST_THREAD_FACTORY=Virtual.

Perhaps these references should use the full `JTREG=TEST_THREAD_FACTORY=Virtual` to make it clearer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21594#discussion_r1808734633

From ihse at openjdk.org  Mon Oct 21 13:05:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:05:13 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <irVXsRVBlVnhU-iZOsdNTZ7Kg-LU52sApukBUSe3qos=.f6f89542-8ec7-4026-97f6-ca4bde99bf73@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2382030332

From stefank at openjdk.org  Mon Oct 21 13:05:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 21 Oct 2024 13:05:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <ykhwOpVpX0wlLZaUM8N1c6NaMVH0hn9UfCikwoTrHkw=.d30174f6-2138-481c-9929-a475fd187a56@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.

?      762     __ movq(index, needle_len);
?
?      763     __ andq(index, 0xf);  // nLen % 16
?      764     __ movq(offset, 0x10);
?      765     __ subq(offset, index);  // 16 - (nLen % 16)
?      766     __ movq(index, offset);
?      767     __ shlq(offset, 1);  // * 2
?      768     __ negq(index);      // -(16 - (nLen % 16))
?
?      769     __ xorq(wr_index, wr_index);
?      770
?      771     __ bind(L_top);
?      772     // load needle and expand 
?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);


We're reading this address:

(SEGV_MAPERR), si_addr: 0x00000007cffffffe


which is just before the start of the heap:

Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3


When this crashed I had:

needle: 0x00000007d000000c
needle_len = 0x12
index = 0xfffffffffffffffe


There has been previous fix to not read past the haystack:
Fix header < 16 bytes in indexOf intrinsic, by @sviswa7
https://github.com/openjdk/jdk/pull/20677/commits/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0

maybe we need something similar for the needle.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426614072

From coleenp at openjdk.org  Mon Oct 21 13:05:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 21 Oct 2024 13:05:14 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <5bn9rl6P9_im5yuUGUuMF6Pn8bcn8nHt1xX6q3b03L4=.0d8ed88a-9599-42b1-9eec-fbab93cf3e37@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

I think a lot of copyright headers need to be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426605597

From ihse at openjdk.org  Mon Oct 21 13:05:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:05:55 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY
In-Reply-To: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
Message-ID: <SexmIZu77XuQ2ulueXs8kpNs4xcuy0puU73e36WxQQw=.d9b00b97-6b1b-48a9-8e13-a81d0bb9ee20@github.com>

On Sun, 20 Oct 2024 02:11:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
> 
> So the below test command will print error:
> 
> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
> 
> 
> Building target 'test' in configuration 'linux-x86_64-server-release'
> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
> RunTests.gmk:206: *** Cannot continue. Stop.
> 
> 
> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21594#pullrequestreview-2382036363

From syan at openjdk.org  Mon Oct 21 13:12:55 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Oct 2024 13:12:55 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY [v2]
In-Reply-To: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
Message-ID: <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>

> Hi all,
> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
> 
> So the below test command will print error:
> 
> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
> 
> 
> Building target 'test' in configuration 'linux-x86_64-server-release'
> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
> RunTests.gmk:206: *** Cannot continue. Stop.
> 
> 
> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.

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

 - JTREG="TEST_THREAD_FACTORY=Virtual"
 - Use JTREG="JTREG_TEST_THREAD_FACTORY=Virtual" to make comment more cleaner

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21594/files
  - new: https://git.openjdk.org/jdk/pull/21594/files/f1aab5dc..7c6a7bb4

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

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

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

From syan at openjdk.org  Mon Oct 21 13:12:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 21 Oct 2024 13:12:56 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY [v2]
In-Reply-To: <idXSvCe8Cs2BcilNzt3MD_7v20mwawBLKv9OhoMuQY8=.a12a4bf8-3463-4feb-ba75-3a4b7fa342bc@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
 <idXSvCe8Cs2BcilNzt3MD_7v20mwawBLKv9OhoMuQY8=.a12a4bf8-3463-4feb-ba75-3a4b7fa342bc@github.com>
Message-ID: <dHDHVA1_KiQzLjdEWBQmS3U312yA7g37UPmRHr6S1hc=.603ec4ee-0d7e-4d91-a83c-432aad1ecf1a@github.com>

On Mon, 21 Oct 2024 12:48:55 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - JTREG="TEST_THREAD_FACTORY=Virtual"
>>  - Use JTREG="JTREG_TEST_THREAD_FACTORY=Virtual" to make comment more cleaner
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 66:
> 
>> 64:         // Virtual threads are not supported by GetObjectMonitorUsage.
>> 65:         // Correct the expected values if the test is executed with
>> 66:         // TEST_THREAD_FACTORY=Virtual.
> 
> Perhaps these references should use the full `JTREG=TEST_THREAD_FACTORY=Virtual` to make it clearer.

Thanks for the review, use `JTREG="TEST_THREAD_FACTORY=Virtual"` to make comment more clearer

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21594#discussion_r1808787158

From ihse at openjdk.org  Mon Oct 21 13:21:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 21 Oct 2024 13:21:25 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY [v2]
In-Reply-To: <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
 <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
Message-ID: <QccrLd6_sqhGEdamvtqplM4M4cqgeq1L2lZyMk4JjaM=.3dba0507-a777-4aa9-8ff4-f048283088f3@github.com>

On Mon, 21 Oct 2024 13:12:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
>> 
>> So the below test command will print error:
>> 
>> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
>> 
>> 
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
>> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
>> RunTests.gmk:206: *** Cannot continue. Stop.
>> 
>> 
>> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JTREG="TEST_THREAD_FACTORY=Virtual"
>  - Use JTREG="JTREG_TEST_THREAD_FACTORY=Virtual" to make comment more cleaner

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21594#pullrequestreview-2382087028

From dfuchs at openjdk.org  Mon Oct 21 13:32:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 13:32:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <RR8acwmQK7Tsg7HTc70yDPcGNetx4ATXhqTt3W0A_kA=.73aff4cf-e9f3-4846-87d8-1866a60c4c74@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Thanks for the changes in JMX and java.logging. Looks good to me.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382119997

From weijun at openjdk.org  Mon Oct 21 13:40:29 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 13:40:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <DbT1eiAQwGpLTPfMJe82_mI6V-P8UY6CcrY925DvDT8=.f9866219-7a75-4251-81fc-7e26db1e3bda@github.com>
 <GPoqnWczXL-BYfh0c7ntdMwabs97O3hQOmYlHBoVYxo=.f3e07c7c-d6e4-4c62-bbb4-1b4726a877f5@github.com>
 <I6tVGhjLr6rYZ-oYvKXlQEx02L80v1F2E6q-6U2bMW0=.26b6991f-1855-4e37-8e55-f0d387b8e033@github.com>
 <yQf0csH5VnTy7UktUafg9UawR82cw9O2mC9RlodkI8Y=.a4969762-3d92-4d69-81d8-4d5ca6547a27@github.com>
 <f_N6AGQqmOOEf6us73PGFYc5rqufuZE8ARrwUqg2_BU=.88d8e3ec-0312-4de8-9330-e96b088d6f0e@github.com>
Message-ID: <-Bc_cBbnZLLWUhNTjFI_T-LLSRXSnDUS-EnV0DTQwVc=.460efd25-1595-4ff6-a262-3c1c90c7ebd0@github.com>

On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I assume for the second one above you mean `javax.security.auth.kerberos.ServicePermission`. These classes still have a lot of words like "grant" and "trust".  I will make some changes to the class descriptions of those classes, please review them in the next update.
>
> See the changes I made in https://github.com/openjdk/jdk/pull/21498/commits/9dd59a12e984c347a34a25e6fd820340b1e12505. Sometimes it is difficult to remove all text about granting the permission, which is why we added the API note in all Permission subclasses stating that the permission can no longer be used to protect resources.

I see. I was wondering why some files are modified and some are not. The new text looks fine to me. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1808841888

From rkennke at openjdk.org  Mon Oct 21 13:56:35 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 13:56:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
Message-ID: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>

On Thu, 17 Oct 2024 10:57:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Compact header riscv (#3)
>   
>   Implement compact headers on RISCV
>   ---------
>   
>   Co-authored-by: hamlin <hamlin at rivosinc.com>

> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
> 
> ```
> ?      762     __ movq(index, needle_len);
> ?
> ?      763     __ andq(index, 0xf);  // nLen % 16
> ?      764     __ movq(offset, 0x10);
> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
> ?      766     __ movq(index, offset);
> ?      767     __ shlq(offset, 1);  // * 2
> ?      768     __ negq(index);      // -(16 - (nLen % 16))
> ?
> ?      769     __ xorq(wr_index, wr_index);
> ?      770
> ?      771     __ bind(L_top);
> ?      772     // load needle and expand 
> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
> ```
> 
> We're reading this address:
> 
> ```
> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
> ```
> 
> which is just before the start of the heap:
> 
> ```
> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
> ```
> 
> When this crashed I had:
> 
> ```
> needle: 0x00000007d000000c
> needle_len = 0x12
> index = 0xfffffffffffffffe
> ```
> 
> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
> 
> maybe we need something similar for the needle.

@sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426754934

From erikj at openjdk.org  Mon Oct 21 14:10:24 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 21 Oct 2024 14:10:24 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY [v2]
In-Reply-To: <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
 <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
Message-ID: <sV0H4P3Zzx3OKNo_1hSewINVcm6PJzvAZZQ4g1vTABQ=.ea728cf7-6eda-4cae-ba24-7db3bed5324c@github.com>

On Mon, 21 Oct 2024 13:12:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
>> 
>> So the below test command will print error:
>> 
>> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
>> 
>> 
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
>> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
>> RunTests.gmk:206: *** Cannot continue. Stop.
>> 
>> 
>> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JTREG="TEST_THREAD_FACTORY=Virtual"
>  - Use JTREG="JTREG_TEST_THREAD_FACTORY=Virtual" to make comment more cleaner

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21594#pullrequestreview-2382234395

From duke at openjdk.org  Mon Oct 21 14:23:53 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 14:23:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <-mco1SNkDsaGs1iPfVA_rYxd2rjKseRvjMMMO1KkDog=.ca9caf95-e6c7-4456-ace6-183c4ef45554@github.com>

On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Compact header riscv (#3)
>>   
>>   Implement compact headers on RISCV
>>   ---------
>>   
>>   Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>> 
>> ```
>> ?      762     __ movq(index, needle_len);
>> ?
>> ?      763     __ andq(index, 0xf);  // nLen % 16
>> ?      764     __ movq(offset, 0x10);
>> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
>> ?      766     __ movq(index, offset);
>> ?      767     __ shlq(offset, 1);  // * 2
>> ?      768     __ negq(index);      // -(16 - (nLen % 16))
>> ?
>> ?      769     __ xorq(wr_index, wr_index);
>> ?      770
>> ?      771     __ bind(L_top);
>> ?      772     // load needle and expand 
>> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>> 
>> We're reading this address:
>> 
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>> 
>> which is just before the start of the heap:
>> 
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>> 
>> When this crashed I had:
>> 
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>> 
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>> 
>> maybe we need something similar for the needle.
> 
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.

@rkennke looking!

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2426828440

From jwaters at openjdk.org  Mon Oct 21 14:40:23 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Oct 2024 14:40:23 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120
Message-ID: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>

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. This will require reviews from core-libs, awt, security, accessibility, jpackage, and whatever team is responsible for HotSpot debugging.

This fix requires C++17, so it will have to wait for the switch to C++17. I will be working towards that in the meantime and addressing the issues that come with changing the language standard elsewhere. This will only go in once the JDK actually starts using C++17

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

Commit messages:
 - Compile as C++17
 - 8342682

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

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

From jwaters at openjdk.org  Mon Oct 21 14:40:24 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 21 Oct 2024 14:40:24 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <LZtYVTd3u1froQc3jZweznA55vX035SkX99tP0sR4Lk=.dd2f388b-b79c-4a01-a7ec-f86370221779@github.com>

On Mon, 21 Oct 2024 14:34:30 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. This will require reviews from core-libs, awt, security, accessibility, jpackage, and whatever team is responsible for HotSpot debugging.
> 
> This fix requires C++17, so it will have to wait for the switch to C++17. I will be working towards that in the meantime and addressing the issues that come with changing the language standard elsewhere. This will only go in once the JDK actually starts using C++17

src/java.desktop/share/native/common/awt/debug/debug_trace.h line 66:

> 64: /* each file includes this flag indicating module trace status */
> 65: #ifdef __cplusplus
> 66: [[maybe_unused]]

I don't particularly like this one, but I haven't managed to find a cleaner solution. This is because a static global in a header is not great to begin with. It's practically begging for an unused-variable error to happen

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1808952439

From weijun at openjdk.org  Mon Oct 21 14:57:39 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 21 Oct 2024 14:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ytYO_77QWIG71O6PlwBm-HJ_k6VqU2-p3Gg56o98SPI=.7e182f8b-45cb-4bd4-83ce-1e5090e3020d@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

The security-related test updates seem good to me. I noticed a few minor issues and pushed three commits (https://github.com/openjdk/jdk-sandbox/commit/807eb6e363cd78f7051ab2512fbb9fe7f72a036c, https://github.com/openjdk/jdk-sandbox/commit/b4f68e36260cba4cb9e3f72e86674666ee04f15b, and https://github.com/openjdk/jdk-sandbox/commit/02b4bf177555eaf2fa732e918448af9ff1efa8bf).

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2426923546

From dfuchs at openjdk.org  Mon Oct 21 15:25:20 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 15:25:20 GMT
Subject: RFR: 8342633:
 javax/management/security/HashedPasswordFileTest.java creates tmp file in src
 dir
In-Reply-To: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
References: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
Message-ID: <Kz81_mL4aI8V352cvjM-dokStYkQITQY0ArHfVs2kC4=.4d4a30d1-49cf-4f01-9601-20bce1de1cc8@github.com>

On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update: HashedPasswordFileTest.java was using System.getProperty("test.src") as a place to _create_ a file.
> 
> jtreg gives us the current working directory for the test invocation as a scratch directory.  Create files there, without reading any property to find another location.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21602#pullrequestreview-2382461596

From dfuchs at openjdk.org  Mon Oct 21 15:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 21 Oct 2024 15:41:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <LgcZ50hJkMyYZe-v5naaW8WmGArxPnhYHfk6SaGqNO0=.a3d70032-1ca1-4e70-af37-40dfb2f52ddf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

For the record I have also reviewed the `java.naming` and `jdk.httpserver` source changes. They look good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427040743

From pchilanomate at openjdk.org  Mon Oct 21 15:45:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:45:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Adjust spacing in test JfrEvents.java
 - Adjust comment in JavaThread.hpp
 - RISC-V: Avoid return misprediction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/6a81ccdc..8c196acd

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

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

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

From pchilanomate at openjdk.org  Mon Oct 21 15:49:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <Bx7ZxmN7WQ5Pa4AEJlqBCWA0keln_Izxxp28-97dUy8=.8c9f8ffa-eb5c-4384-b25e-924b84d44333@github.com>
 <3qGV4MlDsr4MwwWUIE7w7MI3ZGhhujpzYw-1qFzGVVY=.93a8c704-3817-424e-8ac6-99b4e17ee8e4@github.com>
Message-ID: <b52WbjxNH3fHsSRkdt_2lAtyr-lznkZjp4zBrh4QLGU=.9951c7b2-9dbe-433b-8e75-20ba49b57dc0@github.com>

On Fri, 18 Oct 2024 04:21:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 165:
>> 
>>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporal value.
>> 
>> Suggestion:
>> 
>>   // attached thread cases where this field can have a temporary value.
>> 
>> Presumably this is for when the attaching thread is executing the Thread constructor?
>
> Exactly.

Comment adjusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960

From pchilanomate at openjdk.org  Mon Oct 21 15:49:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 21 Oct 2024 15:49:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.21610d00-5911-45ef-aaa6-6726b060168c@github.com>
Message-ID: <wr2gUUNCp_fXQM_ggvjcOSk72PpT3vWBYDmeoL1Bsog=.6c894146-0c97-4989-8613-14ddd1153fef@github.com>

On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Adjust spacing in test JfrEvents.java
>>  - Adjust comment in JavaThread.hpp
>>  - RISC-V: Avoid return misprediction
>
> test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:
> 
>> 321:             var started2 = new AtomicBoolean();
>> 322: 
>> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {
> 
> Suggestion:
> 
>             Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809073267

From wkemper at openjdk.org  Mon Oct 21 15:57:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Oct 2024 15:57:38 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v4]
In-Reply-To: <mbqd_3S_N2z-b7NqIWPnl1U0za1AwWY5lXUZK-KgWoI=.10c8544d-b66a-44c5-add5-2924776e7b29@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <uBJ3HKwo99Z9hOLVImVS43JCUFKCzMA-i4OcaSyw34w=.5b551cc9-9919-4e3f-8e8d-227e536dcd3c@github.com>
 <mbqd_3S_N2z-b7NqIWPnl1U0za1AwWY5lXUZK-KgWoI=.10c8544d-b66a-44c5-add5-2924776e7b29@github.com>
Message-ID: <vsDvcAVYiPLoyUWsg6IsSPM6YlFeGQJL-wJfJK8F_dI=.8ab408ba-4300-4e59-9afe-cf3f87a64c81@github.com>

On Fri, 11 Oct 2024 21:17:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 579:
>> 
>>> 577:   st->print("Status: ");
>>> 578:   if (has_forwarded_objects())                 st->print("has forwarded objects, ");
>>> 579:   if (is_concurrent_mark_in_progress())        st->print("marking, ");
>> 
>> What is this printing when not running with generational mode?
>
> It will print "young marking". We can change this.

https://bugs.openjdk.org/browse/JDK-8342564

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1809085061

From kevinw at openjdk.org  Mon Oct 21 16:12:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 21 Oct 2024 16:12:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <omJgksIX-GqCbQ_Q7xELjlDjaYtk8TlnCfXapHH1EzM=.8baa30f6-5bd9-424b-9cb7-e1e683f04e16@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewing for management, src and test changes look good.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2382585178

From aboldtch at openjdk.org  Mon Oct 21 16:26:27 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 21 Oct 2024 16:26:27 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
Message-ID: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>

On Mon, 21 Oct 2024 15:45:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Adjust spacing in test JfrEvents.java
>  - Adjust comment in JavaThread.hpp
>  - RISC-V: Avoid return misprediction

I've done an initial look through of the hotspot changes.

In addition to my comments, I have looked at two more things.

One is to remove the _waiters reference counter from deflation and only use the _contentions reference counter. As well as tying the _contentions reference counter to the ObjectWaiter, so that it is easier to follow its lifetime, instead of these naked add_to_contentions, now that the ObjectWaiter does not have a straight forward scope, but can be frozen, and thawed on different threads. 46dacdf96999154e808d21e80b4d4e87f73bc802

Then I looked at typing up the thread / lock ids as an enum class 34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Either of these could be future RFEs.

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:

> 229: 
> 230: StubFrame::~StubFrame() {
> 231:   __ epilogue(_use_pop_on_epilogue);

Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
e.g.
```C++
enum return_state_t {
  does_not_return, requires_return, requires_pop_epilogue_return
};

StubFrame::~StubFrame() {
  if (_return_state == does_not_return) {
    __ should_not_reach_here();
  } else {
    __ epilogue(_return_state == requires_pop_epilogue_return);
  }
}

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:

> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.

Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:

> 378:     lea(t2_owner_addr, owner_address);
> 379: 
> 380:     // CAS owner (null => current thread id).

I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 

Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:

> 298:   CodeBlob* cb = top.cb();
> 299: 
> 300:   if (cb->frame_size() == 2) {

Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:

> 311: 
> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);

Is there a reason for the mix of `2` and `frame::metadata_words`?

Maybe this could be
```C++
    intptr_t* const unadjusted_sp = sp;
    sp -= frame::metadata_words;
    sp[-2] = unadjusted_sp[-2];
    sp[-1] = unadjusted_sp[-1];

    log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
                                              " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:

> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
> 1274:   ::continuation_enter_cleanup(masm);
> 1275: }

Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

src/hotspot/cpu/x86/assembler_x86.cpp line 2866:

> 2864:     emit_int32(0);
> 2865:   }
> 2866: }

Is it possible to make this more general and explicit instead of a sequence of bytes?

Something along the lines of:
```C++
  const address tar = L.is_bound() ? target(L) : pc();
  const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);

  InstructionMark im(this);
  emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
  if (!L.is_bound()) {
    // Patch @0x8D opcode
    L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
  }
  // Register and [rip+disp] operand
  emit_modrm(0b00, raw_encode(dst), 0b101);
  // Adjust displacement by sizeof lea instruction
  int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
  assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
  emit_int32(disp);


and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

src/hotspot/share/oops/stackChunkOop.cpp line 471:

> 469:     }
> 470:   }
> 471: }

Can we turn these three very similar loops into one? In my opinion, it is easier to parse.

```C++
void stackChunkOopDesc::copy_lockstack(oop* dst) {
  const int cnt = lockstack_size();
  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
  const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
  const auto get_obj = [&](intptr_t* at) -> oop {
    if (requires_gc_barriers) {
      if (requires_uncompress) {
        return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
      }
      return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
    }
    return *reinterpret_cast<oop*>(at);
  };

  intptr_t* lockstack_start = start_address();
  for (int i = 0; i < cnt; i++) {
    oop mon_owner = get_obj(&lockstack_start[i]);
    assert(oopDesc::is_oop(mon_owner), "not an oop");
    dst[i] = mon_owner;
  }
}

src/hotspot/share/prims/jvmtiExport.cpp line 1681:

> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.

Suggestion:

  // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:

> 2536:   Method* m = hf.interpreter_frame_method();
> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;

Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

src/hotspot/share/runtime/frame.cpp line 535:

> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
> 534:   return thread_addr;
> 535: #endif

With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

src/hotspot/share/runtime/javaThread.cpp line 1545:

> 1543:     if (is_vthread_mounted()) {
> 1544:       // _lock_id is the thread ID of the mounted virtual thread
> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());

What is the interaction here with `switchToCarrierThread` and the window between?

        carrier.setCurrentThread(carrier);
        Thread.setCurrentLockId(this.threadId());

Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

src/hotspot/share/runtime/objectMonitor.hpp line 184:

> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
> 183:   //   DEFLATER_MARKER must *not* have that bit set.
> 184:   static const int64_t DEFLATER_MARKER = 2;

The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

src/hotspot/share/runtime/objectMonitor.hpp line 186:

> 184:   static const int64_t DEFLATER_MARKER = 2;
> 185: 
> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.

Suggestion:

  int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

src/hotspot/share/runtime/synchronizer.cpp line 1467:

> 1465:       markWord dmw = inf->header();
> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {

Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808181783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808189977
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808208652
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808282892
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808261926
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808318304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808358874
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808706427
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808460330
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809032469
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809065834
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809091338
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809092367
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830

From duke at openjdk.org  Mon Oct 21 16:56:35 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 16:56:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <xuz6jeipBqArYVTgblHr2g9l8UCmFrXf8M_3oMJjQZo=.7abd3294-a20e-4605-abc8-d40cd7c6d5a4@github.com>

On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Compact header riscv (#3)
>>   
>>   Implement compact headers on RISCV
>>   ---------
>>   
>>   Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>> 
>> ```
>> ?      762     __ movq(index, needle_len);
>> ?
>> ?      763     __ andq(index, 0xf);  // nLen % 16
>> ?      764     __ movq(offset, 0x10);
>> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
>> ?      766     __ movq(index, offset);
>> ?      767     __ shlq(offset, 1);  // * 2
>> ?      768     __ negq(index);      // -(16 - (nLen % 16))
>> ?
>> ?      769     __ xorq(wr_index, wr_index);
>> ?      770
>> ?      771     __ bind(L_top);
>> ?      772     // load needle and expand 
>> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>> 
>> We're reading this address:
>> 
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>> 
>> which is just before the start of the heap:
>> 
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>> 
>> When this crashed I had:
>> 
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>> 
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>> 
>> maybe we need something similar for the needle.
> 
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.

@rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail.. 

So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java`  and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427232140

From mullan at openjdk.org  Mon Oct 21 17:24:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 21 Oct 2024 17:24:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
Message-ID: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>

On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.

Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2427301539

From rkennke at openjdk.org  Mon Oct 21 18:04:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 18:04:53 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
Message-ID: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>

On Mon, 21 Oct 2024 13:53:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Compact header riscv (#3)
>>   
>>   Implement compact headers on RISCV
>>   ---------
>>   
>>   Co-authored-by: hamlin <hamlin at rivosinc.com>
>
>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>> 
>> ```
>> ?      762     __ movq(index, needle_len);
>> ?
>> ?      763     __ andq(index, 0xf);  // nLen % 16
>> ?      764     __ movq(offset, 0x10);
>> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
>> ?      766     __ movq(index, offset);
>> ?      767     __ shlq(offset, 1);  // * 2
>> ?      768     __ negq(index);      // -(16 - (nLen % 16))
>> ?
>> ?      769     __ xorq(wr_index, wr_index);
>> ?      770
>> ?      771     __ bind(L_top);
>> ?      772     // load needle and expand 
>> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>> ```
>> 
>> We're reading this address:
>> 
>> ```
>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>> ```
>> 
>> which is just before the start of the heap:
>> 
>> ```
>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>> ```
>> 
>> When this crashed I had:
>> 
>> ```
>> needle: 0x00000007d000000c
>> needle_len = 0x12
>> index = 0xfffffffffffffffe
>> ```
>> 
>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>> 
>> maybe we need something similar for the needle.
> 
> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.

> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
> 
> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.

I could reproduce on 3rd try with a fastdebug build with:

make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"


It prints:

Seed set to 636754923980405411


It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:

InitialHeapSize                          = 805306368
MaxHeapSize                              = 805306368
MaxNewSize                               = 268435456


So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`

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

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427375886

From duke at openjdk.org  Mon Oct 21 18:55:52 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 18:55:52 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
 <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
Message-ID: <NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>

On Mon, 21 Oct 2024 18:00:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>> 
>>> ```
>>> ?      762     __ movq(index, needle_len);
>>> ?
>>> ?      763     __ andq(index, 0xf);  // nLen % 16
>>> ?      764     __ movq(offset, 0x10);
>>> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
>>> ?      766     __ movq(index, offset);
>>> ?      767     __ shlq(offset, 1);  // * 2
>>> ?      768     __ negq(index);      // -(16 - (nLen % 16))
>>> ?
>>> ?      769     __ xorq(wr_index, wr_index);
>>> ?      770
>>> ?      771     __ bind(L_top);
>>> ?      772     // load needle and expand 
>>> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>>> ```
>>> 
>>> We're reading this address:
>>> 
>>> ```
>>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>>> ```
>>> 
>>> which is just before the start of the heap:
>>> 
>>> ```
>>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>>> ```
>>> 
>>> When this crashed I had:
>>> 
>>> ```
>>> needle: 0x00000007d000000c
>>> needle_len = 0x12
>>> index = 0xfffffffffffffffe
>>> ```
>>> 
>>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>> 
>>> maybe we need something similar for the needle.
>> 
>> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
>
>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>> 
>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
> 
> I could reproduce on 3rd try with a fastdebug build with:
> 
> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
> 
> 
> It prints:
> 
> Seed set to 636754923980405411
> 
> 
> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
> 
> InitialHeapSize                          = 805306368
> MaxHeapSize                              = 805306368
> MaxNewSize                               = 268435456
> 
> 
> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`

Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427477113

From mdonovan at openjdk.org  Mon Oct 21 19:12:44 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 21 Oct 2024 19:12:44 GMT
Subject: RFR: 8341927: Remove hardcoded SunJCE provider [v2]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <xX4LOcgtiyt9pxQ8_kmdhluWytGAOiHav-MZY5SgOsA=.2b82ed31-4aa1-4d6f-a0c4-743842624112@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  Updated a few more tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/5f07cd8f..83599700

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=00-01

  Stats: 12 lines in 6 files changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From sviswanathan at openjdk.org  Mon Oct 21 19:26:39 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Mon, 21 Oct 2024 19:26:39 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
 <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
 <NN3GcO1kEKz8t-s1nwOkHjwhaO0Gy_Jgyo0oyH-Z_cU=.4fd9a5da-6f34-4343-ba41-3efbcbf826fc@github.com>
Message-ID: <QzE3fKHgOAo9Jpsq7O_cer2evaHfByqgdv5bSU09-08=.6c26375c-26a1-40a9-bb8c-432e2a93c860@github.com>

On Mon, 21 Oct 2024 18:52:46 GMT, Volodymyr Paprotski <duke at openjdk.org> wrote:

> Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify

@rkennke @vpaprotsk Please find attached the patch which should fix the problem.

[smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427536012

From rkennke at openjdk.org  Mon Oct 21 20:34:41 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 21 Oct 2024 20:34:41 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
 <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
Message-ID: <qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>

On Mon, 21 Oct 2024 18:00:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> I've managed to reproduce the ECoreIndexOf crash locally by running with -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. The crash happens on line 773 when reading past the needle.
>>> 
>>> ```
>>> ?      762     __ movq(index, needle_len);
>>> ?
>>> ?      763     __ andq(index, 0xf);  // nLen % 16
>>> ?      764     __ movq(offset, 0x10);
>>> ?      765     __ subq(offset, index);  // 16 - (nLen % 16)
>>> ?      766     __ movq(index, offset);
>>> ?      767     __ shlq(offset, 1);  // * 2
>>> ?      768     __ negq(index);      // -(16 - (nLen % 16))
>>> ?
>>> ?      769     __ xorq(wr_index, wr_index);
>>> ?      770
>>> ?      771     __ bind(L_top);
>>> ?      772     // load needle and expand 
>>> ?      773     __ vpmovzxbw(xmm0, Address(needle, index, Address::times_1), Assembler::AVX_256bit);
>>> ```
>>> 
>>> We're reading this address:
>>> 
>>> ```
>>> (SEGV_MAPERR), si_addr: 0x00000007cffffffe
>>> ```
>>> 
>>> which is just before the start of the heap:
>>> 
>>> ```
>>> Heap address: 0x00000007d0000000, size: 768 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
>>> ```
>>> 
>>> When this crashed I had:
>>> 
>>> ```
>>> needle: 0x00000007d000000c
>>> needle_len = 0x12
>>> index = 0xfffffffffffffffe
>>> ```
>>> 
>>> There has been previous fix to not read past the haystack: Fix header < 16 bytes in indexOf intrinsic, by @sviswa7 [f65ef5d](https://github.com/openjdk/jdk/commit/f65ef5dc325212155a50a2fc3a7f4aad18b8d9d0)
>>> 
>>> maybe we need something similar for the needle.
>> 
>> @sviswa7 @vpaprotsk could you have a look? If we can have a reasonable fix for this soon, we could ship it in this PR, otherwise I'd defer it to a follow-up issue and disable indexOf intrinsic when running with +UseCompactObjectHeaders.
>
>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>> 
>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
> 
> I could reproduce on 3rd try with a fastdebug build with:
> 
> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
> 
> 
> It prints:
> 
> Seed set to 636754923980405411
> 
> 
> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
> 
> InitialHeapSize                          = 805306368
> MaxHeapSize                              = 805306368
> MaxNewSize                               = 268435456
> 
> 
> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`

> > Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
> 
> @rkennke @vpaprotsk Please find attached the patch which should fix the problem.
> 
> [smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)

Testing now. Runs the reproducer in a loop since half an hour without crashing. I'll let it run overnight, and if @vpaprotsk approves the changes, then I'll intergrate them tomorrow morning.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427660618

From iklam at openjdk.org  Mon Oct 21 20:46:56 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:46:56 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v17]
In-Reply-To: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
Message-ID: <i9CMsfCsZHwMP2Qjs0uqKvAvAFRb7PSJqathtN1C36U=.b1d1ed20-b333-4283-997b-a670d8de0a7e@github.com>

> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
> 
> **Overview**
> 
> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
> 
> **All-or-nothing Loading**
> 
> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exact same set of modules are visible whe...

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @calvinccheung review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20843/files
  - new: https://git.openjdk.org/jdk/pull/20843/files/6bb38cb9..9d3d8bd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20843&range=15-16

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20843/head:pull/20843

PR: https://git.openjdk.org/jdk/pull/20843

From iklam at openjdk.org  Mon Oct 21 20:46:59 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 21 Oct 2024 20:46:59 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v12]
In-Reply-To: <RPc2b_gvwmDk9HJ17AD4_FRXpPvQYO1Pm7XuDRJOzRg=.d421f765-2774-49d2-bb06-4354ef664c45@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
 <Qn3nE2T_330O5Ok4ZwoF3_OH_s1WgbygmwbedQ1XiIM=.52fe4ba7-97e3-4342-a90a-60ecbd467746@github.com>
 <RPc2b_gvwmDk9HJ17AD4_FRXpPvQYO1Pm7XuDRJOzRg=.d421f765-2774-49d2-bb06-4354ef664c45@github.com>
Message-ID: <RKCm1z-170BdCErljm25OS-Ju1nx3RuIhFyX3wICaDo=.1ae38066-6b21-42f6-8198-7dacf63f912e@github.com>

On Mon, 23 Sep 2024 17:56:39 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam 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 branch 'jep-483-step-02-8338018-rename-class-prelinker-to-aot-cp-resolver' into jep-483-step-03-8329706-implement-xx-aot-class-linking
>>  - @dholmes-ora comments
>>  - @dholmes-ora comments
>>  - Fixed ZERO build
>>  - minor comment fix
>>  - @ashu-mehra comment: move code outside of call_initPhase2(); also renamed BOOT/BOOT2 to BOOT1/BOOT2 and refactored code related to AOTLinkedClassCategory
>>  - @ashu-mehra reviews
>>  - @ashu-mehra comments
>>  - @adinn comments
>>  - @dholmes-ora comments: logging indents
>>  - ... and 5 more: https://git.openjdk.org/jdk/compare/49dbfa6a...6029b35f
>
> src/hotspot/share/cds/metaspaceShared.cpp line 1536:
> 
>> 1534:   if (lsh.is_enabled()) {
>> 1535:     lsh.print("Using AOT-linked classes: %s (static archive: %s aot-linked classes",
>> 1536:               CDSConfig::is_using_aot_linked_classes() ? "true" : "false",
> 
> Suggestion:
>     `BOOL_TO_STR(CDSConfig::is_using_aot_linked_classes()),`

Fixed.

> test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java line 100:
> 
>> 98:         TestCommon.checkExec(out);
>> 99: 
>> 100:         // JEP 483: if dumped with -XX:+AOTClassLinking, cannot use archive when CFLH
> 
> Suggestion:
>     `..., cannot use archive when CFLH is enabled`

Fixed.

> test/lib/jdk/test/lib/cds/CDSAppTester.java line 50:
> 
>> 48:     public CDSAppTester(String name) {
>> 49:         if (CDSTestUtils.DYNAMIC_DUMP) {
>> 50:             throw new jtreg.SkippedException("Tests based on CDSAppTester should be excluded when -Dtest.dynamic.cds.archive is specified");
> 
> You could omit the `jtreg.` in the above throw statement.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1809504196
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1809504427
PR Review Comment: https://git.openjdk.org/jdk/pull/20843#discussion_r1809504306

From duke at openjdk.org  Mon Oct 21 20:48:23 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 21 Oct 2024 20:48:23 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <R_WaDca9nkuBz7qbRVCynovFC2dFyeHnY62Nbkqqd9A=.668f1165-4c34-4beb-9b95-33808d52ed74@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <R_WaDca9nkuBz7qbRVCynovFC2dFyeHnY62Nbkqqd9A=.668f1165-4c34-4beb-9b95-33808d52ed74@github.com>
Message-ID: <v8Xi5_AzOR_wjTI-qRrJZhuu2lqNFe2iFjumQC1pbOQ=.70ab604e-e035-4d79-bb3a-de4df8a6e409@github.com>

On Sat, 12 Oct 2024 18:42:34 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> 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>
>
> Just an important test or comparison is needed here. Do you have any comparison of  the performance before and after this PR change set? Even if no degrading is expected, better to test it.

Hi @afshin-zafari, I made a [simple test](https://gist.github.com/roberttoyonaga/b2315de83f62ef0f4cef8e4d08ba18d3) and could not find any significant difference in performance. The test basically spawns 16 threads (on my 16 core amd linux machine) and each thread reserves and commits memory thousands of times before finishing. I record how long it takes for all the threads to finish.

 The after 10 trials, the average difference between with/without the mutex change is ~3%, which is less than the stdev (5% of the average values).  It's a pretty rough test, but at least it supports our expectation and shows that there's no obvious degradation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2427685056

From ccheung at openjdk.org  Mon Oct 21 20:59:41 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 21 Oct 2024 20:59:41 GMT
Subject: RFR: 8329706: Implement -XX:+AOTClassLinking [v17]
In-Reply-To: <i9CMsfCsZHwMP2Qjs0uqKvAvAFRb7PSJqathtN1C36U=.b1d1ed20-b333-4283-997b-a670d8de0a7e@github.com>
References: <5cstSdLtxGHWY5aAvTT0RlSVOkuqf5IZ1aN4_VeEHyM=.018c626f-495c-4d49-82ce-712737307701@github.com>
 <i9CMsfCsZHwMP2Qjs0uqKvAvAFRb7PSJqathtN1C36U=.b1d1ed20-b333-4283-997b-a670d8de0a7e@github.com>
Message-ID: <zdwfqBCyVTT4YhFwCU06uPnxjunHUyAYifzSCgrHvSI=.07c01cc3-4017-4f1b-8556-d6ed0b5f687b@github.com>

On Mon, 21 Oct 2024 20:46:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 3rd PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> **Overview**
>> 
>> - A new `-XX:+AOTClassLinking` flag is added. See [JEP 498](https://bugs.openjdk.org/browse/JDK-8315737) and the [CSR](https://bugs.openjdk.org/browse/JDK-8339506) for a discussion of this command-line option, its default value, and its impact on compatibility.
>> - When this flag is enabled during the creation of an AOT cache (aka CDS archive), an `AOTLinkedClassTable` is added to the cache to include all classes that are AOT-linked. For this PR, only classes for the boot/platform/application loaders are eligible. The main logic is in `aotClassLinker.cpp`.
>> - When an AOT archive is loaded in a production run, all classes in the `AOTLinkedClassTable` are loaded into their respective class loaders at the earliest opportunity. The main logic is in `aotLinkedClassBulkLoader.cpp`.
>>   - The boot classes are loaded as part of `vmClasses::resolve_all()`
>>   - The platform/application classes are loaded after the module graph is restored (see changes in `threads.cpp`).
>> - Since all classes in a `AOTLinkedClassTable` are loaded before any user-code is executed, we can resolve constant pool entries that refer to these classes during AOT cache creation. See changes in `AOTConstantPoolResolver::is_class_resolution_deterministic()`.
>> 
>> **All-or-nothing Loading**
>> 
>> - Because AOT-linked classes can refer to each other, using direct C++ pointers, all AOT-linked classes must be loaded together. Otherwise we will have dangling C++ pointers in the class metadata structures. 
>> - During a production run, we check during VM start-up for incompatible VM options that would prevent some of the AOT-linked classes from being loaded. For example:
>>   - If the VM is started with an JVMTI agent that has ClassFileLoadHook capabilities, it could replace some of the AOT-linked classes with alternative versions.
>>   - If the VM is started with certain module options, such as `--patch-module` or `--module`, some AOT-linked classes may be replaced with patched versions, or may become invisible and cannot be loaded into the JVM.
>> - When incompatible VM options are detected, the JVM will refuse to load an AOT cache that has AOT-linked classes. See `FileMapInfo::validate_aot_class_linking()`.
>>   - For simplfication, `FileMapInfo::validate_aot_class_linking()` requires `CDSConfig::is_using_full_module_graph()` to be true. This means that the exa...
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @calvinccheung review comments

Marked as reviewed by ccheung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20843#pullrequestreview-2383296080

From duke at openjdk.org  Mon Oct 21 21:09:38 2024
From: duke at openjdk.org (Volodymyr Paprotski)
Date: Mon, 21 Oct 2024 21:09:38 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v46]
In-Reply-To: <qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TSoqyHiesRchgObQUULLugQ15WdZJlOp21VQTyxrEbQ=.fff7ec53-1145-40e1-90ed-af55b3defb5f@github.com>
 <R_8ZEOsn1sMwBK_6ECrFRv98FrybuIgn1L3tlGFOvcg=.0b947263-39f3-483b-9526-e5fcea4ba603@github.com>
 <BCZjoP4Ao9C1F8kQJmpfooJCnGx3Ef-YNKGHdqZMSCs=.234de599-a258-45ec-9e63-7839f3a48e54@github.com>
 <qXNHwb48lt9LL_DePcb6QLEE0d_rsPQGzI_Bz5Swyzc=.e2d2f513-816d-4bf2-9dbd-67fb74522cfd@github.com>
Message-ID: <fBZr5Zvvl4oTLcO62RFVv9emvEccDwESuB7nNoc8HfI=.a09a0b4b-53a9-4808-9dcd-f0b877e73759@github.com>

On Mon, 21 Oct 2024 20:31:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>>> @rkennke Could you post the full command you used please? And perhaps also the seed that gets printed.. having trouble getting it to fail..
>>> 
>>> So far I added a few options and perrmitations of: `./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xcomp -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+EnableX86ECoreOpts -XX:+UseSerialGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders test/jdk/java/lang/StringBuffer/ECoreIndexOf.java` and lo luck.. IndexOf.java test checks "all interesting" lengths of haystack and needle and can't get it to fail either.
>> 
>> I could reproduce on 3rd try with a fastdebug build with:
>> 
>> make test TEST=java/lang/StringBuffer/ECoreIndexOf.java TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:+UseSerialGC"
>> 
>> 
>> It prints:
>> 
>> Seed set to 636754923980405411
>> 
>> 
>> It probably depends on GC operation: It would only fail when the array happens to be the very first object in the heap. The relevant GC/heap configs would be:
>> 
>> InitialHeapSize                          = 805306368
>> MaxHeapSize                              = 805306368
>> MaxNewSize                               = 268435456
>> 
>> 
>> So you should probably also add `-Xmx805306368 -Xms805306368 -Xmn268435456`
>
>> > Thanks @rkennke able to reproduce now.. Sandhya will have a patch soon and I will re-verify
>> 
>> @rkennke @vpaprotsk Please find attached the patch which should fix the problem.
>> 
>> [smallneedlefix.patch](https://github.com/user-attachments/files/17466073/smallneedlefix.patch)
> 
> Testing now. Runs the reproducer in a loop since half an hour without crashing. I'll let it run overnight, and if @vpaprotsk approves the changes, then I'll intergrate them tomorrow morning.

@rkennke I've been running the patch too, for about 2.5 hours now, looks good to me.

Also looked things over again, looks good. Just to explain/document what I reviewed.. 

- Looked at other uses of the needle (that code didn't change, so not exhaustive claim). Typically size of the needle being less then 16 'doesnt matter'.. i.e. broadcast first char, last char, if first/last character mask matches, switch-table for comparing middle 
     - i.e. no reading headers needed
- The case Sandhya fixes, handles UL special case (i.e. haystack unicode, needle regular). For cases of needle less then 32 bytes, copy the needle to the stack, and expand 8->16 so regular UU code can be used. Previous code looped 256bit loads at a time, now we loop 128 instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2427718674

From wkemper at openjdk.org  Mon Oct 21 21:16:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Oct 2024 21:16:50 GMT
Subject: RFR: 8337511: Implement JEP-404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
Message-ID: <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>

> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:

 - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
 - Merge
 - 8342560: GenShen: Fix confusing method name
   
   Reviewed-by: ysr
 - 8342564: GenShen: Only reference young/old generation names in generational mode
   
   Reviewed-by: xpeng, ysr
 - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
 - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
 - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
   
   Reviewed-by: kdnilsen, ysr
 - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
   
   Reviewed-by: ysr
 - 8342278: GenShen: Move non-generational mode test out of generational test configuration
   
   Reviewed-by: ysr
 - 8342255: GenShen: Remove unnecessary enum initial values
   
   Reviewed-by: ysr
 - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408

-------------

Changes: https://git.openjdk.org/jdk/pull/21273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=04
  Stats: 22825 lines in 229 files changed: 21084 ins; 889 del; 852 mod
  Patch: https://git.openjdk.org/jdk/pull/21273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273

PR: https://git.openjdk.org/jdk/pull/21273

From prr at openjdk.org  Mon Oct 21 21:24:30 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 21 Oct 2024 21:24:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 55:

> 53:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false w.policy
> 54:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest false rw.policy
> 55:  * @run     main/othervm -Djava.security.manager=allow CachePermissionsTest true rwd.policy

Looks to me like we should delete these 3 policy files.
Also this test isn't about Permissions anymore. So should be renamed to CacheUsedTest 
Then we can get rid of the misspelt directory. in a follow up.Probably do this

test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:

> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
> 75: 
> 76:         if (args.length > 1) {

The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?

Also the messing around with exceptions at the end of the test is pointless

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809540920
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809544420

From amenkov at openjdk.org  Tue Oct 22 00:44:15 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 22 Oct 2024 00:44:15 GMT
Subject: RFR: 8342633:
 javax/management/security/HashedPasswordFileTest.java creates tmp file in src
 dir
In-Reply-To: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
References: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
Message-ID: <7nsVEtFl6mygeAPpKe-1ENJGpur2fZjmyDu29qtaPGY=.745fa80d-74d3-4df3-99da-01d430c6d392@github.com>

On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update: HashedPasswordFileTest.java was using System.getProperty("test.src") as a place to _create_ a file.
> 
> jtreg gives us the current working directory for the test invocation as a scratch directory.  Create files there, without reading any property to find another location.

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21602#pullrequestreview-2383533706

From jwaters at openjdk.org  Tue Oct 22 01:46:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 01:46:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
Message-ID: <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>

On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > and whatever team is responsible for HotSpot debugging.
> 
> I don't see anything hotspot related here.
> 
> I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular would prefer that.

Aren't the dt_shmem and jdwp changes related to HotSpot? But I guess I'll split it up in that case, I thought it might have been quicker to group it all together in one shot. This particular Pull Request I'll probably reserve for jdwp and the like, core-libs and client (And everything else) I'll move to their own PRs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428041172

From dholmes at openjdk.org  Tue Oct 22 01:46:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 01:46:19 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>

On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> and whatever team is responsible for HotSpot debugging.

I don't see anything hotspot related here.

I think you would be better off splitting this up into distinct issues and PRs for different areas. I expect the client team in particular would prefer that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428037844

From pchilanomate at openjdk.org  Tue Oct 22 02:14:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:23 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:

 - Fix comments in objectMonitor.hpp
 - Move frame::saved_thread_address() to platform dependent files
 - Fix typo in jvmtiExport.cpp
 - remove usage of frame::metadata_words in possibly_adjust_frame()
 - Fix comments in c2 locking paths
 - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/8c196acd..23d1a2be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=01-02

  Stats: 253 lines in 19 files changed: 122 ins; 97 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 22 02:14:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:14:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>

On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:
> 
>> 229: 
>> 230: StubFrame::~StubFrame() {
>> 231:   __ epilogue(_use_pop_on_epilogue);
> 
> Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
> e.g.
> ```C++
> enum return_state_t {
>   does_not_return, requires_return, requires_pop_epilogue_return
> };
> 
> StubFrame::~StubFrame() {
>   if (_return_state == does_not_return) {
>     __ should_not_reach_here();
>   } else {
>     __ epilogue(_return_state == requires_pop_epilogue_return);
>   }
> }

Yes, that's much better. I changed it in both aarch64 and riscv.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:
> 
>> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
>> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
>> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.
> 
> Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

I removed this comment about what other values might be stored in _owner since we don't need to handle those cases here.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
> 
>> 378:     lea(t2_owner_addr, owner_address);
>> 379: 
>> 380:     // CAS owner (null => current thread id).
> 
> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
> 
> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:
> 
>> 311: 
>> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);
> 
> Is there a reason for the mix of `2` and `frame::metadata_words`?
> 
> Maybe this could be
> ```C++
>     intptr_t* const unadjusted_sp = sp;
>     sp -= frame::metadata_words;
>     sp[-2] = unadjusted_sp[-2];
>     sp[-1] = unadjusted_sp[-1];
> 
>     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>                                               " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

I removed the use of frame::metadata_words from the log statement instead to make it consistent, since we would still implicitly be assuming metadata_words it's 2 words when we do the copying. We could use a memcpy and refer to metadata_words, but I think it is clear this way since we are explicitly talking about the 2 extra words missing from the runtime frame as the comment explains.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809745804
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746249
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746397
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046

From pchilanomate at openjdk.org  Tue Oct 22 02:23:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 02:23:16 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>

On Mon, 21 Oct 2024 07:57:31 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
> 
>> 298:   CodeBlob* cb = top.cb();
>> 299: 
>> 300:   if (cb->frame_size() == 2) {
> 
> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

We could also check the caller of the runtime frame, something like:

#ifdef ASSERT
  RegisterMap map(JavaThread::current(),
                  RegisterMap::UpdateMap::skip,
                  RegisterMap::ProcessFrames::skip,
                  RegisterMap::WalkContinuation::skip);
  frame caller = top.sender(&map);
  assert(caller.is_compiled_frame(), "");
  assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
#endif

Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:
> 
>> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
>> 1274:   ::continuation_enter_cleanup(masm);
>> 1275: }
> 
> Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

Since we have 3 free static functions to handle the continuation entry(create, fill, cleanup) I would prefer to keep the cleanup one for consistency. We could also change them all to be members of SharedRuntime. But except for the exception I added for continuation_enter_cleanup(), all these are called by gen_continuation_enter/gen_continuation_yield() which are also static free functions.

> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
> 
>> 2864:     emit_int32(0);
>> 2865:   }
>> 2866: }
> 
> Is it possible to make this more general and explicit instead of a sequence of bytes?
> 
> Something along the lines of:
> ```C++
>   const address tar = L.is_bound() ? target(L) : pc();
>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
> 
>   InstructionMark im(this);
>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>   if (!L.is_bound()) {
>     // Patch @0x8D opcode
>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>   }
>   // Register and [rip+disp] operand
>   emit_modrm(0b00, raw_encode(dst), 0b101);
>   // Adjust displacement by sizeof lea instruction
>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>   emit_int32(disp);
> 
> 
> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

I'll test it out but looks fine.

> src/hotspot/share/prims/jvmtiExport.cpp line 1681:
> 
>> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.
> 
> Suggestion:
> 
>   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

Fixed.

> src/hotspot/share/runtime/frame.cpp line 535:
> 
>> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
>> 534:   return thread_addr;
>> 535: #endif
> 
> With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

I moved it to the platform dependent files.

> src/hotspot/share/runtime/objectMonitor.hpp line 184:
> 
>> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
>> 183:   //   DEFLATER_MARKER must *not* have that bit set.
>> 184:   static const int64_t DEFLATER_MARKER = 2;
> 
> The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

Removed the comments.

> src/hotspot/share/runtime/objectMonitor.hpp line 186:
> 
>> 184:   static const int64_t DEFLATER_MARKER = 2;
>> 185: 
>> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.
> 
> Suggestion:
> 
>   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

Fixed.

> src/hotspot/share/runtime/synchronizer.cpp line 1467:
> 
>> 1465:       markWord dmw = inf->header();
>> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
>> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {
> 
> Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

Yes, it's just a consequence of using tid as the owner, not really related to freezing. So when a thread inflates a monitor that is already owned we cannot store the BasicLock* in the _owner field anymore, since it can clash with some tid, so we mark it as anonymously owned instead. The owner will fix it here when trying to get the monitor, as we do with LM_LIGHTWEIGHT.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809753868
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749481
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749657
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750552
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750685
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940

From rkennke at openjdk.org  Tue Oct 22 07:32:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 07:32:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v47]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <PT1OZyKSCB7sEfiFsFugK3GTbr1JATJ1X7xP8XlD9-g=.c35de9eb-e8ab-4739-9957-2f7623500d23@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix needle copying in indexOf intrinsic for smaller headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1b907cc8..8c4eb6d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=45-46

  Stats: 16 lines in 1 file changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From dholmes at openjdk.org  Tue Oct 22 07:44:22 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 07:44:22 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

First, congratulations on an exceptional piece of work @pchilano .  

Also thank you for the very clear breakdown and description in the PR as that helps immensely with trying to digest a change of this size.

The overall operational behaviour of this change seems very solid. My only concern is whether the unparker thread may become a bottleneck in some scenarios, but that is a bridge we will have to cross if we come to it.

My initial comments mainly come from just trying to understand the top-level changes around the use of the thread-id as the monitor owner. I have a number of suggestions on naming (mainly `is_x` versus `has_x`) and on documenting the API methods more clearly. None of which are showstoppers and some of which pre-exist. Unfortunately though you will need to fix the spelling of `succesor`.

Thanks

src/hotspot/share/runtime/objectMonitor.hpp line 47:

> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 47: // See next_waiter(), first_waiter(), etc.

This to-do is likely no longer relevant with the current changes.

src/hotspot/share/runtime/objectMonitor.hpp line 288:

> 286:   // Returns true if this OM has an owner, false otherwise.
> 287:   bool      has_owner() const;
> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.

null is not an int64_t value.

src/hotspot/share/runtime/objectMonitor.hpp line 292:

> 290: 
> 291:   static int64_t owner_for(JavaThread* thread);
> 292:   static int64_t owner_for_oop(oop vthread);

Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   // Simply set _owner field to new_value; current value must match old_value.
> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);

Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

src/hotspot/share/runtime/objectMonitor.hpp line 303:

> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 303:   // Simply set _owner field to current; current value must match basic_lock_p.

Comment is no longer accurate

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:   // _owner field. Returns the prior value of the _owner field.
> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);

Similar to set_owner* need better comments describing API.

src/hotspot/share/runtime/objectMonitor.hpp line 311:

> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 310: 
> 311:   bool      is_succesor(JavaThread* thread);

I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

src/hotspot/share/runtime/objectMonitor.hpp line 315:

> 313:   void      set_succesor(oop vthread);
> 314:   void      clear_succesor();
> 315:   bool      has_succesor();

Sorry but `successor` has two `s` before `or`.

src/hotspot/share/runtime/objectMonitor.hpp line 317:

> 315:   bool      has_succesor();
> 316: 
> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }

Again `has_owner` seems more appropriate

src/hotspot/share/runtime/objectMonitor.hpp line 323:

> 321:   }
> 322: 
> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

src/hotspot/share/runtime/objectMonitor.hpp line 333:

> 331:   bool is_stack_locker(JavaThread* current);
> 332:   BasicLock* stack_locker() const;
> 333:   void set_stack_locker(BasicLock* locker);

Again `is` versus `has`, plus some general comments describing the API.

src/hotspot/share/runtime/threadIdentifier.cpp line 30:

> 28: 
> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
> 30: static const int64_t INITIAL_TID = 3;

Can we express this in terms of those reserved values, or are they inaccessible?

src/java.base/share/classes/java/lang/Thread.java line 731:

> 729: 
> 730:         if (attached && VM.initLevel() < 1) {
> 731:             this.tid = 3;  // primordial thread

The comment before the `ThreadIdentifiers` class needs updating to account for this change.

src/java.base/share/classes/java/lang/VirtualThread.java line 109:

> 107:      *
> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter

Should this say something similar to the parked case, about the "yield" being successful?

src/java.base/share/classes/java/lang/VirtualThread.java line 110:

> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue

Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

src/java.base/share/classes/java/lang/VirtualThread.java line 111:

> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter

Presumably this one means it acquired the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 115:

> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
> 114:      *   WAITING -> WAITED         // waiting on monitor
> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner

Waiting to re-enter the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 178:

> 176:     // timed-wait support
> 177:     private long waitTimeout;
> 178:     private byte timedWaitNonce;

Strange name - what does this mean?

src/java.base/share/classes/java/lang/VirtualThread.java line 530:

> 528:                 && carrier == Thread.currentCarrierThread();
> 529:         carrier.setCurrentThread(carrier);
> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread

I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810027786
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810033016
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810035434
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810037658
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810036007
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810041017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810046285
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810049295
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810076019
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810111255
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113028
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810114488
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810116177
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810131339

From psadhukhan at openjdk.org  Tue Oct 22 08:11:35 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:11:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:

> 24: import javax.swing.SwingUtilities;
> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
> 26: /*

I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810185617

From psadhukhan at openjdk.org  Tue Oct 22 08:19:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 08:19:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:

> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
> 48:     }
> 49: 

Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810199838

From kevinw at openjdk.org  Tue Oct 22 08:32:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 22 Oct 2024 08:32:20 GMT
Subject: RFR: 8342633:
 javax/management/security/HashedPasswordFileTest.java creates tmp file in src
 dir
In-Reply-To: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
References: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
Message-ID: <VWCfhis0hPMVrUJgCxUB8nWLf-zFvmbKLEcRlcAp34Q=.52148c59-54f4-43eb-99c0-964d9e711088@github.com>

On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update: HashedPasswordFileTest.java was using System.getProperty("test.src") as a place to _create_ a file.
> 
> jtreg gives us the current working directory for the test invocation as a scratch directory.  Create files there, without reading any property to find another location.

Thanks for reviewing, Daniel and Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21602#issuecomment-2428610104

From kevinw at openjdk.org  Tue Oct 22 08:32:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 22 Oct 2024 08:32:20 GMT
Subject: Integrated: 8342633:
 javax/management/security/HashedPasswordFileTest.java creates tmp file in src
 dir
In-Reply-To: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
References: <O_lyaEng719nCg-8q9HTNTsu4Gschlofk1zaUgcqpKs=.94e56212-6323-4b12-8e5f-54647cb700e1@github.com>
Message-ID: <PrIGeR-Ai1PbV-a-9uiXSVtviWFnJL3ZHxhUu1Ghswg=.20bcbfc5-5286-42cc-91bc-56b1a96c8d7f@github.com>

On Mon, 21 Oct 2024 09:21:35 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update: HashedPasswordFileTest.java was using System.getProperty("test.src") as a place to _create_ a file.
> 
> jtreg gives us the current working directory for the test invocation as a scratch directory.  Create files there, without reading any property to find another location.

This pull request has now been integrated.

Changeset: de441c2b
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de441c2b6891ad475f516d14b793efbe65f1477c
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8342633: javax/management/security/HashedPasswordFileTest.java creates tmp file in src dir

Reviewed-by: dfuchs, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/21602

From psadhukhan at openjdk.org  Tue Oct 22 09:01:38 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:01:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1EhcQfR-j3LoYCg_GkqbbJGXZEEF7PQgXtEfq_MZFZw=.6db08c42-646e-4cc1-b704-07820ae128bb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:

> 29: /**
> 30:  * @test
> 31:  * @key headful

javadoc style /** at the beginning

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810285947

From psadhukhan at openjdk.org  Tue Oct 22 09:07:51 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:07:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <YNmEi00IsUjIq2jyebS_mjfWgyUlkz9lx4Hlw2PE5yc=.e917162c-9b2c-4c14-ace0-f4fe31e4cf5a@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:

> 46:         test.setupUI();
> 47:         test.testApplication();
> 48:         test.testApplet();

I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810297085

From psadhukhan at openjdk.org  Tue Oct 22 09:12:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:12:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <rb-fYphAyA6BGkUU1fouWA9XPKElgZTf13MGIgbv2gc=.1d78026e-00e6-4f0e-b194-a4df08e8688e@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:

> 64:         }
> 65: 
> 66:         // Show popup as if from an applet

remove applet

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810309276

From psadhukhan at openjdk.org  Tue Oct 22 09:19:31 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:19:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <1rvnBCeqVl1aLtZcR0YYv7abOQlZ7WNQrOQgH359CVw=.ad43bb44-7be8-429b-aea7-ea4cd8ad507c@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:

> 115:             }
> 116:             popup.setVisible(false);
> 117:             frame.dispose();

The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:

> 27:  * @test
> 28:  * @bug 6622002
> 29:  * @author Alexander Potochkin

remove @author tag

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810327184
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810331078

From psadhukhan at openjdk.org  Tue Oct 22 09:32:33 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 22 Oct 2024 09:32:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:

> 43:         JTable table = new JTable();
> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
> 45:         if (de == null) {

I guess we can test this without SM since it tests SwingLazyValue?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810353747

From dholmes at openjdk.org  Tue Oct 22 09:43:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 09:43:41 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
 <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
Message-ID: <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>

On Tue, 22 Oct 2024 01:43:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Aren't the dt_shmem and jdwp changes related to HotSpot? 

Nope. That's core-svc - the non-hotspot side of serviceability. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2428793636

From kevinw at openjdk.org  Tue Oct 22 10:16:20 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 22 Oct 2024 10:16:20 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
Message-ID: <LSHgGan69AlMpFiMintZJuPsLjBd1V9uv2uegPgeklw=.50d73448-6079-4c5f-9898-5ce54565d656@github.com>

On Tue, 15 Oct 2024 22:31:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated comment
>  - feedback

test/hotspot/jtreg/serviceability/attach/AttachAPIv2/CompatTest.java line 48:

> 46:     public static void main(String[] args) throws Exception {
> 47:         // if the test (client part) in the "compat" mode
> 48:         boolean clientCompat = "true".equals(System.getProperty("jdk.attach.compat"));

Boolean.getBoolean("jdk.attach.compat") ignores case for us as well.
But more generally, are we happy with "jdk.attach.compat" as a boolean flag, or would "jdk.attach.version" be better?
(which is mainly asking if we think there might ever be another version!)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1810432507

From rkennke at openjdk.org  Tue Oct 22 11:19:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 11:19:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v48]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:

 - Merge tag 'jdk-24+20' into JDK-8305895-v4
   
   Added tag jdk-24+20 for changeset 7a64fbbb
 - Fix needle copying in indexOf intrinsic for smaller headers
 - Compact header riscv (#3)
   
   Implement compact headers on RISCV
   ---------
   
   Co-authored-by: hamlin <hamlin at rivosinc.com>
 - Remove extra sanity check
 - Problem-list SharedBaseAddress tests on aarch64
 - Address comments by @vpaprotsk
 - Fix aarch64.ad
 - Merge tag 'jdk-24+19' into JDK-8305895-v4
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - PPC64 implementation of Compact Object Headers (JEP 450)
 - Increase compiler code stubs size for indexOf intrinsic
 - ... and 87 more: https://git.openjdk.org/jdk/compare/7a64fbbb...e324d95b

-------------

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=47
  Stats: 5021 lines in 212 files changed: 3472 ins; 847 del; 702 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From jwaters at openjdk.org  Tue Oct 22 11:35:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 22 Oct 2024 11:35:39 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <G9zEvP0ul85NYYG9M6umOuYjuaDhWIPM_qxsMJCtKoI=.1cdbc31a-56cd-412c-8abf-cde29fc8b5a7@github.com>
 <-zfrUge_9zAFIlJQB-L2oytEBTLluINYiNlbkCFkCTE=.db445cce-343f-4792-bfa7-1ea22d453d46@github.com>
 <3kfD7hXMBKj93H04sYwW60CpKwCJUbwgfBpDnC9aMj8=.84120ba5-8e46-4711-b220-ec23d5d5f296@github.com>
Message-ID: <AZW9odbdZiZH_ctLd_GOU3cXw6rLoYTvav_YqiqHOaE=.418db53f-3ddc-4886-9dd4-60e2e5369150@github.com>

On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Aren't the dt_shmem and jdwp changes related to HotSpot?
> 
> Nope. That's core-svc - the non-hotspot side of serviceability. :)

Oh, well I guess you learn something new everyday :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2429033577

From michaelm at openjdk.org  Tue Oct 22 11:53:39 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 22 Oct 2024 11:53:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

test/jdk/java/net/URLPermission/OpenURL.java line 30:

> 28:  * @run main/othervm OpenURL
> 29:  */
> 30: 

Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2384948510
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810575350

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>

On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/javaThread.cpp line 1545:
> 
>> 1543:     if (is_vthread_mounted()) {
>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
> 
> What is the interaction here with `switchToCarrierThread` and the window between?
> 
>         carrier.setCurrentThread(carrier);
>         Thread.setCurrentLockId(this.threadId());
> 
> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.

In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179

From alanb at openjdk.org  Tue Oct 22 11:58:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 11:58:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>

On Tue, 22 Oct 2024 07:28:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
> 
>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>> 114:      *   WAITING -> WAITED         // waiting on monitor
>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
> 
> Waiting to re-enter the monitor?

yes

> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
> 
>> 176:     // timed-wait support
>> 177:     private long waitTimeout;
>> 178:     private byte timedWaitNonce;
> 
> Strange name - what does this mean?

Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267

From alanb at openjdk.org  Tue Oct 22 12:08:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:08:19 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>

On Tue, 22 Oct 2024 07:39:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
> 
>> 528:                 && carrier == Thread.currentCarrierThread();
>> 529:         carrier.setCurrentThread(carrier);
>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
> 
> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).

More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265

From dholmes at openjdk.org  Tue Oct 22 12:20:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 22 Oct 2024 12:20:13 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
Message-ID: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>

On Tue, 22 Oct 2024 12:05:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
>> 
>>> 528:                 && carrier == Thread.currentCarrierThread();
>>> 529:         carrier.setCurrentThread(carrier);
>>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
>> 
>> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??
>
> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
> 
> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

Okay but ....
1. We have the current virtual thread
2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473

From alanb at openjdk.org  Tue Oct 22 12:34:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 22 Oct 2024 12:34:28 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
Message-ID: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>

On Tue, 22 Oct 2024 12:17:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
>> 
>> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.
>
> Okay but ....
> 1. We have the current virtual thread
> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960

From stefank at openjdk.org  Tue Oct 22 13:29:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 13:29:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v48]
In-Reply-To: <H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <H6cywVFrD2hUSGZd1VCGpMu7OmP0ON0RC2QQaLJFBb8=.3960b3bb-8273-472c-9d3e-655638447762@github.com>
Message-ID: <4UtypHyHundxF7XNmcIsoarpmt4EcfgEzSO4uoobf3Q=.0351e5bb-000e-4068-a5e4-3e3db19a61a0@github.com>

On Tue, 22 Oct 2024 11:19:19 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge tag 'jdk-24+20' into JDK-8305895-v4
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Fix needle copying in indexOf intrinsic for smaller headers
>  - Compact header riscv (#3)
>    
>    Implement compact headers on RISCV
>    ---------
>    
>    Co-authored-by: hamlin <hamlin at rivosinc.com>
>  - Remove extra sanity check
>  - Problem-list SharedBaseAddress tests on aarch64
>  - Address comments by @vpaprotsk
>  - Fix aarch64.ad
>  - Merge tag 'jdk-24+19' into JDK-8305895-v4
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - PPC64 implementation of Compact Object Headers (JEP 450)
>  - Increase compiler code stubs size for indexOf intrinsic
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/7a64fbbb...e324d95b

We've identified another failure in our testing:

java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:TieredStopAtLevel=2 -XX:TLABSize=1 -XX:MinTLABSize=1 ~/tests/HelloWorld.java
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp:50), pid=775231, tid=775232
#  assert(desired_tlab_size_bytes > alignment_reserve_bytes) failed: invariant
...
V  [libjvm.so+0xf4ec11]  JfrObjectAllocationSample::send_event(Klass const*, unsigned long, bool, Thread*)+0x2d1  (jfrObjectAllocationSample.cpp:50)
V  [libjvm.so+0x5d7899]  AllocTracer::send_allocation_outside_tlab(Klass*, HeapWordImpl**, unsigned long, JavaThread*)+0x39  (allocTracer.cpp:35)
V  [libjvm.so+0x139d6c5]  MemAllocator::Allocation::notify_allocation_jfr_sampler()+0x225  (memAllocator.cpp:214)
V  [libjvm.so+0x139f928]  MemAllocator::allocate() const+0x2a8  (memAllocator.cpp:235)
V  [libjvm.so+0x18379bd]  TypeArrayKlass::allocate_common(int, bool, JavaThread*)+0x13d  (collectedHeap.inline.hpp:41)
V  [libjvm.so+0x14bc5c8]  oopFactory::new_typeArray(BasicType, int, JavaThread*)+0x38  (typeArrayKlass.hpp:68)
V  [libjvm.so+0x8327f1]  Runtime1::new_type_array(JavaThread*, Klass*, int)+0xa1  (c1_Runtime1.cpp:388)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2429286279

From dfuchs at openjdk.org  Tue Oct 22 13:37:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 13:37:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <6p0_cedTrQLTFNxCqb97IyWI1coUVKx24hh4vU0nWCw=.7cb573d4-36dc-4c69-94d2-7d0c96201b14@github.com>
Message-ID: <AOTi73-spmeUDB5J44UY2JsXYmZN9rNHl8oXlXTlgDQ=.f159726c-1867-4c4e-9a44-86bd185f763c@github.com>

On Tue, 22 Oct 2024 11:50:13 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/URLPermission/OpenURL.java line 30:
> 
>> 28:  * @run main/othervm OpenURL
>> 29:  */
>> 30: 
> 
> Do we need to keep this test at all? Or if keeping it, does it need the HTTP server simulation, since the bug only relates to the URLPermission instantiation? The test could be reduced to just the URL creation followed by the URLPermission.

It could - but technically openConnection / getInputStream could still throw if there was an issue with the provided URL. The difference here is that with a SecurityManager the connection would be rejected with a SecurityException before the connection was made. Without a security manager, the connection will go through, so you need the server simulation (can't rely on getting IOException assuming nobody would be listening).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810741690

From hannesw at openjdk.org  Tue Oct 22 13:41:27 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 13:41:27 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
Message-ID: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>

Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.

We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.

I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

-------------

Commit messages:
 - 8342827: Fix order of @param tags in other modules

Changes: https://git.openjdk.org/jdk/pull/21637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342827
  Stats: 144 lines in 28 files changed: 58 ins; 58 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21637/head:pull/21637

PR: https://git.openjdk.org/jdk/pull/21637

From aboldtch at openjdk.org  Tue Oct 22 13:50:32 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:50:32 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <qvYgffEQcyKQk1ojTcELnXVEQHQj1VcKgP-WxTiGVIE=.a50014b9-52d2-48ac-a5c7-4c506f68db09@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:

> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
> 2246: 
> 2247:     chunk->set_lockstack_size(0);

After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.

Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.


diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
index d3d63533eed..f737bd2db71 100644
--- a/src/hotspot/share/oops/stackChunkOop.cpp
+++ b/src/hotspot/share/oops/stackChunkOop.cpp
@@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
   }
 }
 
+void stackChunkOopDesc::clear_lockstack() {
+  const int cnt = lockstack_size();
+  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
+  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
+  const auto clear_obj = [&](intptr_t* at) {
+    if (requires_uncompress) {
+      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
+    } else {
+      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
+    }
+  };
+
+  if (requires_gc_barriers) {
+    intptr_t* lockstack_start = start_address();
+    for (int i = 0; i < cnt; i++) {
+      clear_obj(&lockstack_start[i]);
+    }
+  }
+  set_lockstack_size(0);
+  set_has_lockstack(false);
+}
+
 void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
   if (*((juint*)this) == badHeapWordVal) {
     st->print_cr("BAD WORD");
diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
index 28e0576801e..928e94dd695 100644
--- a/src/hotspot/share/oops/stackChunkOop.hpp
+++ b/src/hotspot/share/oops/stackChunkOop.hpp
@@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
   void fix_thawed_frame(const frame& f, const RegisterMapT* map);
 
   void copy_lockstack(oop* start);
+  void clear_lockstack();
 
   template <typename OopT, class StackChunkLockStackClosureType>
   inline void iterate_lockstack(StackChunkLockStackClosureType* closure);
diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 5b6e48a02f3..e7d505bb9b1 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -2244,8 +2244,7 @@ NOINLINE intptr_t* Thaw<ConfigT>::thaw_slow(stackChunkOop chunk, Continuation::t
     chunk->copy_lockstack(tmp_lockstack);
     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
 
-    chunk->set_lockstack_size(0);
-    chunk->set_has_lockstack(false);
+    chunk->clear_lockstack();
     retry_fast_path = true;
   }
 ```

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911

From aboldtch at openjdk.org  Tue Oct 22 13:54:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 22 Oct 2024 13:54:36 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:

> 2232:     retry_fast_path = true;
> 2233:   } else {
> 2234:     relativize_chunk_concurrently(chunk);

Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 

While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765

From stuefe at openjdk.org  Tue Oct 22 13:56:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 22 Oct 2024 13:56:42 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
Message-ID: <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>

On Thu, 19 Sep 2024 13:34:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Do you seen any effects of this in anything other than special-crafted micro benchmarks? I wonder if it would be good enough to hard-code this to be 10 for the first integration of Lilliput.
>
> I will do some benchmarks

I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to Klass alignment of 64, 256 and 1K. Benchmark scores did not show a significant pattern. I did not measure CPU stats though. 

But I still think a dynamically calculated shift makes sense, and I hesitate to change this code at this point. I therefore would like to move this question to followup RFEs if necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1810775878

From dfuchs at openjdk.org  Tue Oct 22 14:15:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 22 Oct 2024 14:15:40 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Changes to java.management, java.naming, and sctp look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2385344473

From sgehwolf at openjdk.org  Tue Oct 22 14:18:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 22 Oct 2024 14:18:50 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v11]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <64ooaT_1G3AIl9kLn2ms8Q4GoNLequhhcD05LIETN3g=.449e4916-2770-48f6-b5a8-aa07d6ffeab6@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 36 commits:

 - 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
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
 - ... and 26 more: https://git.openjdk.org/jdk/compare/2da7f2bc...a3989e80

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=10
  Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 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 rkennke at openjdk.org  Tue Oct 22 14:25:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 14:25:12 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v49]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <x0CFyry6L7aq-kozLc85_MEo96bqnhen9RwrExALE4Q=.47b94dc7-94a9-443e-b607-8c873f54daf8@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/e324d95b..19d05e43

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=47-48

  Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From jpai at openjdk.org  Tue Oct 22 15:08:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 22 Oct 2024 15:08:16 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429541439

From aph at openjdk.org  Tue Oct 22 15:26:30 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:26:30 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

>     * We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519

From mullan at openjdk.org  Tue Oct 22 15:28:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 22 Oct 2024 15:28:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
Message-ID: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>

On Tue, 22 Oct 2024 08:09:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
> 
>> 24: import javax.swing.SwingUtilities;
>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>> 26: /*
> 
> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
> 
>> 29: /**
>> 30:  * @test
>> 31:  * @key headful
> 
> javadoc style /** at the beginning

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 66:
> 
>> 64:         }
>> 65: 
>> 66:         // Show popup as if from an applet
> 
> remove applet

Not specific to JEP 486, this should be done as part of a different issue.

> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 6622002
>> 29:  * @author Alexander Potochkin
> 
> remove @author tag

Not specific to JEP 486, this should be done as part of a different issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810939227
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810942471
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943153
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1810943359

From aph at openjdk.org  Tue Oct 22 15:40:14 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:40:14 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:

> 58: 
> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);

Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647

From aph at openjdk.org  Tue Oct 22 15:53:21 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:21 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
Message-ID: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>

On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
> 
>> 58: 
>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
> 
> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810985771

From aph at openjdk.org  Tue Oct 22 15:53:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:53:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
Message-ID: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Fix comments in objectMonitor.hpp
>  - Move frame::saved_thread_address() to platform dependent files
>  - Fix typo in jvmtiExport.cpp
>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>  - Fix comments in c2 locking paths
>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:

> 5339: 
> 5340: void MacroAssembler::inc_held_monitor_count() {
> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::inc_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:

> 5355: 
> 5356: void MacroAssembler::dec_held_monitor_count() {
> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::dec_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022

From aph at openjdk.org  Tue Oct 22 15:58:24 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 22 Oct 2024 15:58:24 GMT
Subject: RFR: 8338383: Implementation of Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
Message-ID: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>

On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>> 
>>> 58: 
>>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
>> 
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
>> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
>
> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810998545

From rsunderbabu at openjdk.org  Tue Oct 22 15:59:18 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 22 Oct 2024 15:59:18 GMT
Subject: RFR: 8202100: merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
Message-ID: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>

Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.

Testing done for
Tiers 1,2,3
test/hotspot/jtreg tests

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8202100
  Stats: 223 lines in 7 files changed: 87 ins; 126 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21641/head:pull/21641

PR: https://git.openjdk.org/jdk/pull/21641

From wkemper at openjdk.org  Tue Oct 22 16:01:47 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 22 Oct 2024 16:01:47 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <GWpGtSgoRD5u1L7TwA7URqGqlBPMsdQH1_tYFR6uzCY=.309147f4-194a-47eb-882f-c7bfcfcbaf00@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <GWpGtSgoRD5u1L7TwA7URqGqlBPMsdQH1_tYFR6uzCY=.309147f4-194a-47eb-882f-c7bfcfcbaf00@github.com>
Message-ID: <yK_kL5aNjuY2GfOFgToHwrahIuyf97G4ufow0iPSRZA=.9d771ea0-806e-45f9-81f5-99a0374c4502@github.com>

On Wed, 9 Oct 2024 03:26:30 GMT, Liang Mao <lmao at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options?
> ```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc*  -XX:MetaspaceSize=1g   -jar specjbb2015.jar -m COMPOSITE```

@mmyxym , Thank you for testing this out! I apologize for not responding to your comment sooner. We run specjbb2015 regularly in our integration pipeline. We see a slight improvement with the generational mode; certainly no regression:

Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3620, critical-jOPS = 2375
Gen:  RUN RESULT: hbIR (max attempted) = 3934, hbIR (settled) = 3295, max-jOPS = 4013, critical-jOPS = 2470
Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3667, critical-jOPS = 2397
Gen:  RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3996, critical-jOPS = 2414

These results were produced with these arguments:

-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticV
MOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xmx10g -Xms10g -XX:ShenandoahGCMode=generational

These runs executed on a Graviton2 host with 4 cores, 16G. I'll run again on a host with more cores and with your exact command line parameters.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2429671754

From rkennke at openjdk.org  Tue Oct 22 16:19:24 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 16:19:24 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright
 - Avoid assert/endless-loop in JFR code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/19d05e43..1ef6394d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=48-49

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Tue Oct 22 16:26:39 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 22 Oct 2024 16:26:39 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>

On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Avoid assert/endless-loop in JFR code

@egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2429724926

From iklam at openjdk.org  Tue Oct 22 16:36:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 16:36:50 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking
Message-ID: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>

This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).

----
Note: this is a combined PR of the following individual PRs
- https://github.com/openjdk/jdk/pull/20516
- https://github.com/openjdk/jdk/pull/20517
- https://github.com/openjdk/jdk/pull/20843
- https://github.com/openjdk/jdk/pull/20958
- https://github.com/openjdk/jdk/pull/20959
- https://github.com/openjdk/jdk/pull/21049
- https://github.com/openjdk/jdk/pull/21143

-------------

Commit messages:
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
 - @calvinccheung review comments
 - @coleenp: No need to hold InvokeMethodIntrinsicTable_lock during bootstrap
 - Better fix for JDK-8342438: runtime/cds/SharedBaseAddress.java fails with Parallel and Serial GCs when running with AOTClassLinking enabled
 - (1) @ashu-mehra review comments - code simplfication; (2) fix bug in last commit
 - @DanHeidinga comments - removed dead code; added assert with ArchiveBuilder::has_been_buffered(src_ik)
 - Fixed JDK-8342732: java/lang/invoke/MethodTypeSecurityManager.java fails with "should never leak JDK internal class" in case AOTClassLinking enabled
 - ... and 142 more: https://git.openjdk.org/jdk/compare/8d0975a2...f0bc1ae6

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331497
  Stats: 6713 lines in 104 files changed: 5835 ins; 560 del; 318 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From hannesw at openjdk.org  Tue Oct 22 16:52:37 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:37 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <Ff95QlflSPml-VI2PtOJIDwMoZHq5LsMQwh1xmC1jVI=.182865f5-d5fa-4393-961b-9b9dfdfb8f7b@github.com>
Message-ID: <6rbSFaQrFn1gW7D8VtU2EqAQr4WoZKBdnapd9w3yEIU=.50bab757-b312-4b84-a220-e88fdd1f3bed@github.com>

On Tue, 22 Oct 2024 15:05:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hello Hannes, since `@param` requires a parameter name and since javadoc already warns about incorrect `@param` names (that don't match the name of the method parameter), does the order in which the `@param` is listed in the javadoc text matter? I looked at https://bugs.openjdk.org/browse/JDK-8279931 but that doesn't tell why the order would be important.

@jaikiran it does not matter for the generated documentation because we already [put the tags in the correct order][JDK-8234682]. So it's purely a code hygiene issue to make doc comments easier to read and maintain. 

[JDK-8234682]: https://bugs.openjdk.org/browse/JDK-8234682

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429770979

From hannesw at openjdk.org  Tue Oct 22 16:52:44 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Tue, 22 Oct 2024 16:52:44 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <7dvcSAoeYSlu137kdlpuB6oUI-6kaMGogh_NrE5_uF8=.8337effa-84c6-40c7-a14e-73a4dfbce783@github.com>
Message-ID: <Ts-V7wU5tk83HEaK9oM4ECkbp8gfZF5vUPceOTp75sY=.4dd2318d-bfdd-4f40-956f-fe4fe3268585@github.com>

On Tue, 22 Oct 2024 14:12:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Changes to java.management, java.naming, and sctp look good to me.

Thanks @dfuch, setting reviewers to 2 for changes in the the remaining modules.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2429782605

From prr at openjdk.org  Tue Oct 22 16:53:19 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 22 Oct 2024 16:53:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
Message-ID: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>

On Tue, 22 Oct 2024 15:22:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/8080972/TestBasicComboBoxEditor.java line 26:
>> 
>>> 24: import javax.swing.SwingUtilities;
>>> 25: import javax.swing.plaf.basic.BasicComboBoxEditor;
>>> 26: /*
>> 
>> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
>
> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.

Agreed. This is not a "clean up / update tests" task.
If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

>> test/jdk/javax/swing/JOptionPane/8081019/bug8081019.java line 31:
>> 
>>> 29: /**
>>> 30:  * @test
>>> 31:  * @key headful
>> 
>> javadoc style /** at the beginning
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed. No need to touch.

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 29:
>> 
>>> 27:  * @test
>>> 28:  * @bug 6622002
>>> 29:  * @author Alexander Potochkin
>> 
>> remove @author tag
>
> Not specific to JEP 486, this should be done as part of a different issue.

agreed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811067982
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811068956
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811070418

From zgu at openjdk.org  Tue Oct 22 17:15:17 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 22 Oct 2024 17:15:17 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v3]
In-Reply-To: <GWpGtSgoRD5u1L7TwA7URqGqlBPMsdQH1_tYFR6uzCY=.309147f4-194a-47eb-882f-c7bfcfcbaf00@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <pLB45ckLnKHk0gDs4o_MV-7E2C2sogJOerr5Vu84CTI=.b9c439de-980d-42cd-aeef-575744f3c414@github.com>
 <GWpGtSgoRD5u1L7TwA7URqGqlBPMsdQH1_tYFR6uzCY=.309147f4-194a-47eb-882f-c7bfcfcbaf00@github.com>
Message-ID: <b5jJoMTKoxqyNgyMDdLlIg1pr1C1pQMdd-S7fyVHIg0=.5b1ab26d-295c-4935-bac9-c77a7f260884@github.com>

On Wed, 9 Oct 2024 03:26:30 GMT, Liang Mao <lmao at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 478 commits:
>> 
>>  - Fix merge error
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8341099: GenShen: assert(HAS_FWD == _heap->has_forwarded_objects()) failed: Forwarded object status is sane
>>    
>>    Reviewed-by: kdnilsen
>>  - 8341485: GenShen: Make evac tracker a non-product feature and confine it to generational mode
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - Merge
>>  - 8341042: GenShen: Reset mark bitmaps for unaffiliated regions when preparing for a cycle
>>    
>>    Reviewed-by: kdnilsen
>>  - 8339616: GenShen: Introduce new state to distinguish promote-in-place phase as distinct from concurrent evacuation
>>    
>>    Reviewed-by: kdnilsen, shade, ysr
>>  - ... and 468 more: https://git.openjdk.org/jdk/compare/b9db74a6...4db1e0e1
>
> Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options?
> ```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc*  -XX:MetaspaceSize=1g   -jar specjbb2015.jar -m COMPOSITE```

> @mmyxym , Thank you for testing this out! I apologize for not responding to your comment sooner. We run specjbb2015 regularly in our integration pipeline. We see a slight improvement with the generational mode; certainly no regression:
> 
> ```
> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3620, critical-jOPS = 2375
> Gen:  RUN RESULT: hbIR (max attempted) = 3934, hbIR (settled) = 3295, max-jOPS = 4013, critical-jOPS = 2470
> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3667, critical-jOPS = 2397
> Gen:  RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3996, critical-jOPS = 2414
> ```
> 
> These results were produced with these arguments:
> 
> ```
> -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticV
> MOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xmx10g -Xms10g -XX:ShenandoahGCMode=generational
> ```
> 
> These runs executed on a Graviton2 host with 4 cores, 16G. I'll run again on a host with more cores and with your exact command line parameters.

What's the reason to disable tiered compilation?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2429827638

From kvn at openjdk.org  Tue Oct 22 17:23:09 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 22 Oct 2024 17:23:09 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <VwR8x8eHX4GRS-eJ8Jews-1USq4IA7IntX_ssJ3h7Wo=.abc387cc-b46a-4ffb-b683-f182a74b988d@github.com>

On Tue, 22 Oct 2024 16:19:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Approved.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2385847834

From coleenp at openjdk.org  Tue Oct 22 17:28:05 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 22 Oct 2024 17:28:05 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <bpO0qexhYiUbhHlwypP3HzCXTElcHPuXZO2IM_-EPrE=.d62d3df4-a209-4ce1-b3d7-ebc33197b2a3@github.com>

On Tue, 22 Oct 2024 15:52:27 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

I've occasionally run into this duplication and am happy you're fixing it.

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 228:

> 226:     }
> 227: 
> 228:     public static Map<String, byte[]> compile(Map<String, ? extends CharSequence> inputMap) {

Could the tests that use this 'compile' be easily fixed to use the below version of 'compile' so you can delete this too?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21641#pullrequestreview-2385856947
PR Review Comment: https://git.openjdk.org/jdk/pull/21641#discussion_r1811119284

From cjplummer at openjdk.org  Tue Oct 22 18:06:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 22 Oct 2024 18:06:08 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>

On Mon, 21 Oct 2024 14:34:30 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

src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:

> 45: {
> 46:     void *mappedMemory;
> 47:  // HANDLE memHandle;

Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.

src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:

> 51: #ifndef _WIN32
> 52: static MUTEX_T my_mutex = MUTEX_INIT;
> 53: #endif

The reason for no reference on windows is because of the following on windows:


#define MUTEX_LOCK(x)           /* FIXUP? */
#define MUTEX_UNLOCK(x)         /* FIXUP? */


So looks like this mutex support is something we never got around to. I think your current workaround is fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811166232
PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811154735

From lmesnik at openjdk.org  Tue Oct 22 18:26:15 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 22 Oct 2024 18:26:15 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
In-Reply-To: <bpO0qexhYiUbhHlwypP3HzCXTElcHPuXZO2IM_-EPrE=.d62d3df4-a209-4ce1-b3d7-ebc33197b2a3@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
 <bpO0qexhYiUbhHlwypP3HzCXTElcHPuXZO2IM_-EPrE=.d62d3df4-a209-4ce1-b3d7-ebc33197b2a3@github.com>
Message-ID: <AAtK1JckFXrb7s-eZ5YZLEXSBuBplEO1LGtrZG0bAEM=.5a933f76-2306-4653-816c-ee2fbdd6c62f@github.com>

On Tue, 22 Oct 2024 17:24:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
>> 
>> Testing done for
>> Tiers 1,2,3
>> test/hotspot/jtreg tests
>
> test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 228:
> 
>> 226:     }
>> 227: 
>> 228:     public static Map<String, byte[]> compile(Map<String, ? extends CharSequence> inputMap) {
> 
> Could the tests that use this 'compile' be easily fixed to use the below version of 'compile' so you can delete this too?

Agree, most of tests should be updated to use compile(String className ...)
and remove wrapping the single file into Map.

While there are tests that need this method to compile several source files as a single batch.

This comments should be added to this method , and it might be renamed to clearly says that it compile a batch of files.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21641#discussion_r1811182608

From lmesnik at openjdk.org  Tue Oct 22 18:26:14 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 22 Oct 2024 18:26:14 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <WFgzY7AZDw-sFNXqyIW-09Irr2Ju6a36_FlPFY9NFJk=.f52ca127-c89d-46a1-9c18-f3572c94b201@github.com>

On Tue, 22 Oct 2024 15:52:27 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

Changes requested by lmesnik (Reviewer).

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 173:

> 171: 
> 172:     // Wraper for class file
> 173:     static class ClassFile extends SimpleJavaFileObject {

The original class has 
MemoryJavaFileObject
already which could be removed now once we have 
ClassFile and SourceFile

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 243:

> 241:             System.out.println(writer.toString());
> 242:             System.out.println("*********** javac output end ***********");
> 243:             if (writer.toString().contains("java.lang.OutOfMemoryError")) {

I don't think we need separate OOME handling. Not sure it ever can happens.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21641#pullrequestreview-2385956062
PR Review Comment: https://git.openjdk.org/jdk/pull/21641#discussion_r1811190699
PR Review Comment: https://git.openjdk.org/jdk/pull/21641#discussion_r1811184213

From wkemper at openjdk.org  Tue Oct 22 18:28:23 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 22 Oct 2024 18:28:23 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
Message-ID: <ABXS9VGZgO5rYX2O_cjToFf5Mv1kDSia2hMvA95BbGM=.01ddfdca-38e4-4440-b677-811a2f9c6805@github.com>

On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8342560: GenShen: Fix confusing method name
>    
>    Reviewed-by: ysr
>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>    
>    Reviewed-by: xpeng, ysr
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>    
>    Reviewed-by: kdnilsen, ysr
>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>    
>    Reviewed-by: ysr
>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>    
>    Reviewed-by: ysr
>  - 8342255: GenShen: Remove unnecessary enum initial values
>    
>    Reviewed-by: ysr
>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408

We disabled tiered compilation to force everything to compile through C2 to get more consistent results.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2429963097

From amenkov at openjdk.org  Tue Oct 22 18:33:09 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 22 Oct 2024 18:33:09 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <LSHgGan69AlMpFiMintZJuPsLjBd1V9uv2uegPgeklw=.50d73448-6079-4c5f-9898-5ce54565d656@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
 <LSHgGan69AlMpFiMintZJuPsLjBd1V9uv2uegPgeklw=.50d73448-6079-4c5f-9898-5ce54565d656@github.com>
Message-ID: <DfALXuQK-Ew92mKLmhuAlf_cKk6Dt4OKyzFGIZSaAM4=.07e25909-b582-4255-aec2-f5185db9bdec@github.com>

On Tue, 22 Oct 2024 10:12:10 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated comment
>>  - feedback
>
> test/hotspot/jtreg/serviceability/attach/AttachAPIv2/CompatTest.java line 48:
> 
>> 46:     public static void main(String[] args) throws Exception {
>> 47:         // if the test (client part) in the "compat" mode
>> 48:         boolean clientCompat = "true".equals(System.getProperty("jdk.attach.compat"));
> 
> Boolean.getBoolean("jdk.attach.compat") ignores case for us as well.
> But more generally, are we happy with "jdk.attach.compat" as a boolean flag, or would "jdk.attach.version" be better?
> (which is mainly asking if we think there might ever be another version!)

I thought about making the property numeric, but that adds complexity in the logic and I don't think  we will need another version soon. Anyway it's internal property for testing only, so we can change it any time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1811198803

From dhanalla at openjdk.org  Tue Oct 22 18:42:13 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Tue, 22 Oct 2024 18:42:13 GMT
Subject: Withdrawn: 8337408: Use GetTempPath2 API instead of GetTempPath
In-Reply-To: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
References: <f1-U-9gZCGjlhcMAnNvRLgLn3yjTPZa7mAe-HD2eVHA=.b4469623-a50d-42ca-8ab8-3ea719dc3e31@github.com>
Message-ID: <jnYtYinpbHGCOqYASitMQXUfLHwkJPMFzKFz-CCPbS4=.81adf8f3-dc79-4af8-a1e6-d41377cb8ab9@github.com>

On Thu, 15 Aug 2024 16:23:18 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code across the OpenJDK repository to retrieve the temporary directory path, as GetTempPath2 provides enhanced security. While GetTempPath may still function without errors, using GetTempPath2 reduces the risk of potential exploits for users.
> 
> 
> The code to dynamically load GetTempPath2 is duplicated due to the following reasons.  I would appreciate any suggestions to remove the duplication where possible:
> 
> 1. The changes span across four different folders?java.base, jdk.package, jdk.attach, and hotspot?with no shared code between them.
> 2. Some parts of the code use version A, while others use version W (ANSI vs. Unicode).
> 3. Some parts of the code are written in C others in C++.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20600

From pchilanomate at openjdk.org  Tue Oct 22 19:01:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:01:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Make lea with RIP-relative addressing more general

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/23d1a2be..81e5c6d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02-03

  Stats: 24 lines in 2 files changed: 7 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 22 19:07:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
Message-ID: <LXvYQLMhjGyozdv2SaLbBGAv7rujDnS1jd9JyvUTHBw=.8a7c1706-9df3-4d17-b6e1-a230db585669@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
>> 
>>> 2864:     emit_int32(0);
>>> 2865:   }
>>> 2866: }
>> 
>> Is it possible to make this more general and explicit instead of a sequence of bytes?
>> 
>> Something along the lines of:
>> ```C++
>>   const address tar = L.is_bound() ? target(L) : pc();
>>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
>> 
>>   InstructionMark im(this);
>>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>>   if (!L.is_bound()) {
>>     // Patch @0x8D opcode
>>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>>   }
>>   // Register and [rip+disp] operand
>>   emit_modrm(0b00, raw_encode(dst), 0b101);
>>   // Adjust displacement by sizeof lea instruction
>>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>>   emit_int32(disp);
>> 
>> 
>> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.
>
> I'll test it out but looks fine.

Done. I simplified the code a bit to make it more readable. It also follows the current style of keeping the cases separate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811237106

From pchilanomate at openjdk.org  Tue Oct 22 19:07:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
Message-ID: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>

On Tue, 22 Oct 2024 13:51:26 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
> 
>> 2232:     retry_fast_path = true;
>> 2233:   } else {
>> 2234:     relativize_chunk_concurrently(chunk);
> 
> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
> 
> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
> 
>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>> 2246: 
>> 2247:     chunk->set_lockstack_size(0);
> 
> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
> 
> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
> 
> 
> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
> index d3d63533eed..f737bd2db71 100644
> --- a/src/hotspot/share/oops/stackChunkOop.cpp
> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>    }
>  }
>  
> +void stackChunkOopDesc::clear_lockstack() {
> +  const int cnt = lockstack_size();
> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
> +  const auto clear_obj = [&](intptr_t* at) {
> +    if (requires_uncompress) {
> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
> +    } else {
> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> +    }
> +  };
> +
> +  if (requires_gc_barriers) {
> +    intptr_t* lockstack_start = start_address();
> +    for (int i = 0; i < cnt; i++) {
> +      clear_obj(&lockstack_start[i]);
> +    }
> +  }
> +  set_lockstack_size(0);
> +  set_has_lockstack(false);
> +}
> +
>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>    if (*((juint*)this) == badHeapWordVal) {
>      st->print_cr("BAD WORD");
> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
> index 28e0576801e..928e94dd695 100644
> --- a/src/hotspot/share/oops/stackChunkOop.hpp
> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>  
>    void copy_lockstack(oop* start);
> +  void clear_lockstack();
>  
>    template <typename OopT, class StackChunkLockSta...

Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206

From pchilanomate at openjdk.org  Tue Oct 22 19:07:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 22 Oct 2024 19:07:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
Message-ID: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>

On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1545:
>> 
>>> 1543:     if (is_vthread_mounted()) {
>>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
>> 
>> What is the interaction here with `switchToCarrierThread` and the window between?
>> 
>>         carrier.setCurrentThread(carrier);
>>         Thread.setCurrentLockId(this.threadId());
>> 
>> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).
>
> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
> 
> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811240529

From sspitsyn at openjdk.org  Tue Oct 22 19:08:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 22 Oct 2024 19:08:07 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v7]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <BX67eE8zK3X9gZ_tt7Okz6KH77uV6CDn9N_IjDDd5AE=.af5c0df4-a97d-48aa-b566-cafe67ae3c89@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: explain better what methods can be annotated with JvmtiMountTransition

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/94862c30..d59d499e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Tue Oct 22 19:16:21 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 22 Oct 2024 19:16:21 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v8]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge
 - review: explain better what methods can be annotated with JvmtiMountTransition
 - review: clarify the use of annotation @JvmtiMountTransition in yield/yield0
 - review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller
 - review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames
 - Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
 - review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two
 - fix one more place with trailing spaces
 - fix trailing spaces
 - add new test coverage with  vthread/CheckHiddenFrames
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d6eddcda...54dc2b4a

-------------

Changes: https://git.openjdk.org/jdk/pull/21397/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=07
  Stats: 282 lines in 11 files changed: 236 ins; 18 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From stefank at openjdk.org  Tue Oct 22 20:11:27 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Oct 2024 20:11:27 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <8O2eaSeTC3JyNsCK6Tb-RGi8NzbA17M5S0mnuF_szo0=.f7da9bb1-fd4b-47df-a56c-e6803182dd27@github.com>

On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Avoid assert/endless-loop in JFR code

Our testing has found a failure in serviceability/sa/ClhsdbJstackWithConcurrentLock.java when we run C1-only.

I've narrowed it down to be a stale, but seemingly working, implementation of the TLAB data structure. When Lilliput changes the header size this implementation doesn't work anymore and needs to be fixed.

The reproducer for this problem is:

make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"


See how the thread reports that the frame holds an AOS, but the list of "Locked ownable synchronizers" is (incorrectly) empty:

"Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
 - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
 - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
 - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
 - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
 - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
 - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
 - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
 - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)

Locked ownable synchronizers:
    - None


This happens because the TLAB ranges become overlapped and that confuses the rest of the SA code that looks for objects in the heap.

I've created a fix for this, which I intend to try to get pushed to openjdk/jdk:
https://github.com/openjdk/jdk/compare/pr/20677...stefank:jdk:8342857_SA_heap_iterator_fix
https://github.com/stefank/jdk/tree/8342857_SA_heap_iterator_fix

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2430157348

From iklam at openjdk.org  Tue Oct 22 20:35:38 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 22 Oct 2024 20:35:38 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v2]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 157 commits:

 - @rose00 offline comments -- make sure the StringConcatFactory bsm does not use MethodTypes that refer to excluded classes
 - Added test case for using --module-path with -XX:+AOTClassLinking
 - @rose00 comment -- print size of MH intrinsics table
 - @stefank comment: include aotLinkedClassBulkLoader.hpp in iterator.inline.hpp
 - Merge branch 'master' into jep-483-candidate
 - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
 - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
 - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
 - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
 - @calvinccheung review comments
 - ... and 147 more: https://git.openjdk.org/jdk/compare/893266c4...3860dcf5

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=01
  Stats: 6929 lines in 102 files changed: 6051 ins; 560 del; 318 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From honkar at openjdk.org  Tue Oct 22 20:52:28 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:52:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <CkRcFjfurFSz7TjPgF5jqUyjfutH-vBHQvmHLYXNB7Y=.cd1bac46-fd00-4186-aca8-91476983b976@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

@prsadhuk Addressed review comments in the following jep486 branch commit: 
https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e

1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430237067

From honkar at openjdk.org  Tue Oct 22 20:58:31 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 20:58:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
Message-ID: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>

On Tue, 22 Oct 2024 08:16:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
> 
>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>> 48:     }
>> 49: 
> 
> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...

Updated

> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 48:
> 
>> 46:         test.setupUI();
>> 47:         test.testApplication();
>> 48:         test.testApplet();
> 
> I guess we can only remove this `testApplet` as SM is invoked there only....we can still test `testApplication`, right?

Updated. Repurposed the test.

> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
> 
>> 115:             }
>> 116:             popup.setVisible(false);
>> 117:             frame.dispose();
> 
> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..

Updated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811381885
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382077
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811382336

From honkar at openjdk.org  Tue Oct 22 21:04:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 22 Oct 2024 21:04:30 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
Message-ID: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>

On Tue, 22 Oct 2024 09:29:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
> 
>> 43:         JTable table = new JTable();
>> 44:         TableCellEditor de = table.getDefaultEditor(Double.class);
>> 45:         if (de == null) {
> 
> I guess we can test this without SM since it tests SwingLazyValue?

I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811400040

From mchung at openjdk.org  Tue Oct 22 21:39:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 22 Oct 2024 21:39:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:

> 29:  * @summary test that all fields returned by getDeclaredFields() can be
> 30:  *          set accessible if the right permission is granted; this test
> 31:  *          also verifies that Class.classLoader final private field is

"if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:

> 336: 
> 337:     public static enum TestCase {
> 338:         UNSECURE;

Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:

> 43: 
> 44:     public static void main(String... args) throws Throwable {
> 45:         System.err.println("Test without security manager.");

Security manager is not relevant any more.  Suggest to drop this println.

test/jdk/java/lang/invoke/RevealDirectTest.java line 33:

> 31:  * @test
> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest

line 36 can also be removed.


* $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java line 77:

> 75:             @Override
> 76:             public boolean implies(ProtectionDomain domain, Permission p) {
> 77:                 return perms.implies(p) || DEFAULT_POLICY.implies(domain, p);

static variable `DEFAULT_POLICY` (line 48) can be removed.

test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:

> 81:     }
> 82: 
> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";

This constant is no longer needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2383401067
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809627796
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809631220
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811445313
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811458290
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811462419
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1809602637

From cjplummer at openjdk.org  Tue Oct 22 21:54:16 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 22 Oct 2024 21:54:16 GMT
Subject: RFR: 8342673: Test
 serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
 failed: waited too long for notify
Message-ID: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>

Fix deadlock with suspending the main thread while it is in Thread.join() to join the thread that is suspending it. The suspending thread then waits for a FRAME_POP event on the main thread, but that never happens because it is suspended.

Testing in progress. Running the test 100 times on all supported platforms, including separate run with `-Xcomp`.

-------------

Commit messages:
 - Fix deadlock during join()

Changes: https://git.openjdk.org/jdk/pull/21650/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21650&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342673
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21650.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21650/head:pull/21650

PR: https://git.openjdk.org/jdk/pull/21650

From amenkov at openjdk.org  Tue Oct 22 22:19:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 22 Oct 2024 22:19:04 GMT
Subject: RFR: 8342673: Test
 serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
 failed: waited too long for notify
In-Reply-To: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
References: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
Message-ID: <NJV85o8p4WCfFGVvQRVcA5zRDagMe9PP8OS0UPJ1vaY=.0f9140a6-87c4-437f-86f9-54d0e6ad1645@github.com>

On Tue, 22 Oct 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix deadlock with suspending the main thread while it is in Thread.join() to join the thread that is suspending it. The suspending thread then waits for a FRAME_POP event on the main thread, but that never happens because it is suspended.
> 
> Testing in progress. Running the test 100 times on all supported platforms, including separate run with `-Xcomp`.

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21650#pullrequestreview-2386495745

From liach at openjdk.org  Tue Oct 22 23:37:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Oct 2024 23:37:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v2]
In-Reply-To: <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <F32HoOoJ-FD_jqo-HCGLm2uY19PGBlj_2IAn0uxN4Eg=.1382e2f7-2c6e-4dba-ad9c-3b114142bc44@github.com>
Message-ID: <GUv4VHuVpvx73tYpt363tKmnoEdt1DOhlG54ccEzEBA=.e594738e-0f26-430d-b87a-f30e4c446b2d@github.com>

On Tue, 22 Oct 2024 20:35:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 157 commits:
> 
>  - @rose00 offline comments -- make sure the StringConcatFactory bsm does not use MethodTypes that refer to excluded classes
>  - Added test case for using --module-path with -XX:+AOTClassLinking
>  - @rose00 comment -- print size of MH intrinsics table
>  - @stefank comment: include aotLinkedClassBulkLoader.hpp in iterator.inline.hpp
>  - Merge branch 'master' into jep-483-candidate
>  - Merge branch 'jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke' into jep-483-step-07-8293336-store-lambda-forms-in-cds-archive
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap' into jep-483-step-05-8293337-archive-method-handle-intrinsics
>  - Merge branch 'jep-483-step-03-8329706-implement-xx-aot-class-linking' of /jdk3/yak/open into jep-483-step-04-8293187-support-sun-invoke-util-wrapper-in-cds-archive-heap
>  - @calvinccheung review comments
>  - ... and 147 more: https://git.openjdk.org/jdk/compare/893266c4...3860dcf5

The java file changes look good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2386587967

From lmesnik at openjdk.org  Tue Oct 22 23:53:04 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 22 Oct 2024 23:53:04 GMT
Subject: RFR: 8342673: Test
 serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
 failed: waited too long for notify
In-Reply-To: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
References: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
Message-ID: <kYN9ZM2E66b8RE3dfjE_G0Sq1GMVuCwnEUAxhsVHWAE=.d166ea75-9088-4b0e-97f8-7605811596b9@github.com>

On Tue, 22 Oct 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix deadlock with suspending the main thread while it is in Thread.join() to join the thread that is suspending it. The suspending thread then waits for a FRAME_POP event on the main thread, but that never happens because it is suspended.
> 
> Testing in progress. Running the test 100 times on all supported platforms, including separate run with `-Xcomp`.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21650#pullrequestreview-2386602336

From coleenp at openjdk.org  Wed Oct 23 00:02:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 00:02:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <i_kRTAV64HcQosNOwa19e2Ezu5advIOT9r6KQ9lfRnA=.f2194af6-509c-4cdf-8f29-0b78071114a0@github.com>

On Tue, 22 Oct 2024 19:01:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make lea with RIP-relative addressing more general

> Then I looked at typing up the thread / lock ids as an enum class https://github.com/openjdk/jdk/commit/34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Both of these suggested changes should be discussed as different RFEs.  I don't really like this ThreadID change because it seems to introduce casting everywhere.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701

From sspitsyn at openjdk.org  Wed Oct 23 00:18:03 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 23 Oct 2024 00:18:03 GMT
Subject: RFR: 8342673: Test
 serviceability/jvmti/events/NotifyFramePopStressTest/NotifyFramePopStressTest.java
 failed: waited too long for notify
In-Reply-To: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
References: <4Cu4vnXTPHf9WmWmXdgjVoYe2r_92aHAuVBLcl9iqq8=.8bb0aff9-ac1a-482d-bc07-2e33cc180a34@github.com>
Message-ID: <6eRm7O7OeKu3zAnc236fkCL8R9Xm8qkRV9cCTQLVytQ=.1365f7a4-8ee5-484a-99f4-abef7c87dca3@github.com>

On Tue, 22 Oct 2024 21:49:59 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Fix deadlock with suspending the main thread while it is in Thread.join() to join the thread that is suspending it. The suspending thread then waits for a FRAME_POP event on the main thread, but that never happens because it is suspended.
> 
> Testing in progress. Running the test 100 times on all supported platforms, including separate run with `-Xcomp`.

It is good. Thank you for fixing it!

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21650#pullrequestreview-2386620786

From pchilanomate at openjdk.org  Wed Oct 23 00:35:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Address David's comments to ObjectMonitor.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/81e5c6d0..b6bc98e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03-04

  Stats: 147 lines in 11 files changed: 10 ins; 7 del; 130 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 23 00:35:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:35:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <ERnhebjKvn3xuNnBLCTfZXgc4ak-2z3Cpl5l5y8K3js=.031eb960-544a-4149-b930-aa37b31b0219@github.com>

On Tue, 22 Oct 2024 06:27:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/objectMonitor.hpp line 47:
> 
>> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 47: // See next_waiter(), first_waiter(), etc.
> 
> This to-do is likely no longer relevant with the current changes.

Removed.

> src/hotspot/share/runtime/objectMonitor.hpp line 288:
> 
>> 286:   // Returns true if this OM has an owner, false otherwise.
>> 287:   bool      has_owner() const;
>> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.
> 
> null is not an int64_t value.

Changed to NO_OWNER.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855

From pchilanomate at openjdk.org  Wed Oct 23 00:41:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 00:41:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>

On Tue, 22 Oct 2024 06:31:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/objectMonitor.hpp line 292:
> 
>> 290: 
>> 291:   static int64_t owner_for(JavaThread* thread);
>> 292:   static int64_t owner_for_oop(oop vthread);
> 
> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 
> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

> src/hotspot/share/runtime/objectMonitor.hpp line 303:
> 
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 303:   // Simply set _owner field to current; current value must match basic_lock_p.
> 
> Comment is no longer accurate

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:   // _owner field. Returns the prior value of the _owner field.
>> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 
> Similar to set_owner* need better comments describing API.

Added similar comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 311:
> 
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
>> 310: 
>> 311:   bool      is_succesor(JavaThread* thread);
> 
> I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

Right, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 315:
> 
>> 313:   void      set_succesor(oop vthread);
>> 314:   void      clear_succesor();
>> 315:   bool      has_succesor();
> 
> Sorry but `successor` has two `s` before `or`.

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 317:
> 
>> 315:   bool      has_succesor();
>> 316: 
>> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }
> 
> Again `has_owner` seems more appropriate

Yes, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 323:
> 
>> 321:   }
>> 322: 
>> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

I changed it to `has_owner_anonymous`.

> src/hotspot/share/runtime/objectMonitor.hpp line 333:
> 
>> 331:   bool is_stack_locker(JavaThread* current);
>> 332:   BasicLock* stack_locker() const;
>> 333:   void set_stack_locker(BasicLock* locker);
> 
> Again `is` versus `has`, plus some general comments describing the API.

Fixed and added comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601098
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601168
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601545
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601472
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601619
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601871
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811602000

From rsunderbabu at openjdk.org  Wed Oct 23 00:44:07 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 23 Oct 2024 00:44:07 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
In-Reply-To: <bpO0qexhYiUbhHlwypP3HzCXTElcHPuXZO2IM_-EPrE=.d62d3df4-a209-4ce1-b3d7-ebc33197b2a3@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
 <bpO0qexhYiUbhHlwypP3HzCXTElcHPuXZO2IM_-EPrE=.d62d3df4-a209-4ce1-b3d7-ebc33197b2a3@github.com>
Message-ID: <j4nQfHzrAOihs9mgZLlxXwee-Jod2OWwMaLlB9rnYZ8=.5d293303-29b1-4fbb-ada5-76bd6205484b@github.com>

On Tue, 22 Oct 2024 17:25:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
>> 
>> Testing done for
>> Tiers 1,2,3
>> test/hotspot/jtreg tests
>
> I've occasionally run into this duplication and am happy you're fixing it.

Thanks @coleenp and @lmesnik for the review.
Only in vmTestbase/metaspace/stressHierarchy/common/generateHierarchy/GenerateHierarchyHelper.java, the batch compile is used. Even there, we could replace it with iteration of single compiles.
I will remove all the instances of batch compile and keep the InMemoryJavaCompiler clean and simple.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21641#issuecomment-2430570943

From coleenp at openjdk.org  Wed Oct 23 01:22:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OOgK-ahqwHKpvAp4ojoQfikKfX-ehfP4LIUZnTFWtI8=.0e9d4552-195c-41b5-8fda-e6b111f1821c@github.com>
Message-ID: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.784030c7-ecc1-4b8f-ae85-cbd2e68304b0@github.com>

On Tue, 22 Oct 2024 19:01:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make lea with RIP-relative addressing more general

I've done a first pass over the first commit and have some comments and questions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214

From coleenp at openjdk.org  Wed Oct 23 01:22:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.97e5685a-5a09-489c-92c0-a5d8d5a3a87d@github.com>
Message-ID: <vc7yb0rPrCsvTFxlSjVuCowEFqyXNl89l6Ls2eVYS4g=.beb72a45-9822-41cd-8b96-ed74a2472532@github.com>

On Tue, 22 Oct 2024 02:09:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
>> 
>>> 378:     lea(t2_owner_addr, owner_address);
>>> 379: 
>>> 380:     // CAS owner (null => current thread id).
>> 
>> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
>> 
>> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)
>
> Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

yes, we preferred lock_id here which is the same as the Java version of thread id, but not the same as the os thread-id.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811583503

From coleenp at openjdk.org  Wed Oct 23 01:22:10 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>

On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
> 
>> 5339: 
>> 5340: void MacroAssembler::inc_held_monitor_count() {
>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::inc_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Also, is it better to have this without assignment.  Which is a nit.
Address dst(rthread, JavaThread::held_monitor_count_offset());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811584584

From coleenp at openjdk.org  Wed Oct 23 01:22:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:

> 5352:   str(rscratch2, dst);
> 5353:   Label ok;
> 5354:   tbz(rscratch2, 63, ok);

63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2629:

> 2627:   addi(temp, displaced_header, in_bytes(ObjectMonitor::owner_offset()) - markWord::monitor_value);
> 2628:   Register thread_id = displaced_header;
> 2629:   ld(thread_id, in_bytes(JavaThread::lock_id_offset()), R16_thread);

Maybe to make things really clear, you could call this thread_lock_id ?

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:

> 229: 
> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());

Address dst(xthread, JavaThread::held_monitor_count_offset());

src/hotspot/share/runtime/javaThread.cpp line 2002:

> 2000: #ifdef SUPPORT_MONITOR_COUNT
> 2001: 
> 2002: #ifdef LOOM_MONITOR_SUPPORT

If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

src/hotspot/share/runtime/objectMonitor.cpp line 416:

> 414:     set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.
> 415:     return true;
> 416:   }

Not needed? Oh I see, BasicLock is now in stack_locker.

src/hotspot/share/runtime/objectMonitor.cpp line 1014:

> 1012:   assert_mark_word_consistency();
> 1013:   UnlinkAfterAcquire(current, currentNode);
> 1014:   if (is_succesor(current)) clear_succesor();

successor has two 's'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811591482
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811595282
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453

From coleenp at openjdk.org  Wed Oct 23 01:22:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 01:22:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <eXYawRQQVqA8NLFgpPr-H1F1oLdu1Ka-Yk4npkyi298=.8acffd05-cd72-4377-8732-2e453e3181c7@github.com>

On Wed, 23 Oct 2024 00:37:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 315:
>> 
>>> 313:   void      set_succesor(oop vthread);
>>> 314:   void      clear_succesor();
>>> 315:   bool      has_succesor();
>> 
>> Sorry but `successor` has two `s` before `or`.
>
> Fixed.

Yes, need to fix successor spelling.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558

From psadhukhan at openjdk.org  Wed Oct 23 03:10:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>

On Tue, 22 Oct 2024 16:44:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This should be addressed in a more general separate task, and not part of this PR since it does not have anything to do with the changes in this JEP.
>
> Agreed. This is not a "clean up / update tests" task.
> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.

I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811704257

From psadhukhan at openjdk.org  Wed Oct 23 03:10:32 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:10:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <BhXyfrLOvAdzoIDfhbCHSeahv9kA7Yt6g9bTufm394k=.cb3057f8-aeef-42cf-8a23-71602c0531cb@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 36:

> 34: import javax.swing.SwingUtilities;
> 35: 
> 36: /*

this here the order is changed...

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 24:

> 22:  */
> 23: 
> 24: /**

again here the import and tag order is changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811705627
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811706135

From psadhukhan at openjdk.org  Wed Oct 23 03:19:28 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 03:19:28 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
Message-ID: <hBSgrNiQ1XrBiepIl60-kesAatcE7Flw6_cRwQRDIpA=.846ab6c0-0855-4f0d-a9d8-91831587dfae@github.com>

On Tue, 22 Oct 2024 16:46:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> Not specific to JEP 486, this should be done as part of a different issue.
>
> agreed

there were many tests modified in javax_swing in this PR where the author tag is removed, only this is missed so I pointed it out...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811724308

From iklam at openjdk.org  Wed Oct 23 04:46:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 23 Oct 2024 04:46:51 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v3]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with three additional commits since the last revision:

 - fixed test failure with "jtreg -Dtest.dynamic.cds.archive=true ..."
 - simplified the archiving of cpCache::resolved_references() -- we rely on AOTConstantPoolResolver::is_indy_resolution_deterministic() to do the filtering before indys are linked; there is no need to try to undo the resolved_references afterwards
 - Fixed bug where the BSM oops for resolved indies are not archived

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/3860dcf5..1b6c3e28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=01-02

  Stats: 78 lines in 5 files changed: 28 ins; 39 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From psadhukhan at openjdk.org  Wed Oct 23 05:14:36 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 23 Oct 2024 05:14:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
> 
>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
> 
>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
> 
>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
> 
>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
> 
> 
> Left out comments that fall into out-of-scope/clean-up for jep486.

looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2430919687

From dholmes at openjdk.org  Wed Oct 23 05:21:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:21:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
Message-ID: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>

On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay but ....
>> 1. We have the current virtual thread
>> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
>> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?
>
> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.

Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811877637

From jwaters at openjdk.org  Wed Oct 23 05:26:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 23 Oct 2024 05:26:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
Message-ID: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>

On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer <cjplummer 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
>
> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
> 
>> 45: {
>> 46:     void *mappedMemory;
>> 47:  // HANDLE memHandle;
> 
> Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.

I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead

> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
> 
>> 51: #ifndef _WIN32
>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>> 53: #endif
> 
> The reason for no reference on windows is because of the following on windows:
> 
> 
> #define MUTEX_LOCK(x)           /* FIXUP? */
> #define MUTEX_UNLOCK(x)         /* FIXUP? */
> 
> 
> So looks like this mutex support is something we never got around to. I think your current workaround is fine.

I'm curious now, how to implement mutex support on Windows? I think I prefer that to just making it completely unavailable on Windows

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811884490
PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1811885815

From aboldtch at openjdk.org  Wed Oct 23 05:38:11 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:38:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
Message-ID: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>

On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>> 
>>> 2232:     retry_fast_path = true;
>>> 2233:   } else {
>>> 2234:     relativize_chunk_concurrently(chunk);
>> 
>> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
>> 
>> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.
>
> Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

Something along those lines, yes.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
>> 
>>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>>> 2246: 
>>> 2247:     chunk->set_lockstack_size(0);
>> 
>> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
>> 
>> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
>> 
>> 
>> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
>> index d3d63533eed..f737bd2db71 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.cpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
>> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>>    }
>>  }
>>  
>> +void stackChunkOopDesc::clear_lockstack() {
>> +  const int cnt = lockstack_size();
>> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
>> +  const auto clear_obj = [&](intptr_t* at) {
>> +    if (requires_uncompress) {
>> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
>> +    } else {
>> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
>> +    }
>> +  };
>> +
>> +  if (requires_gc_barriers) {
>> +    intptr_t* lockstack_start = start_address();
>> +    for (int i = 0; i < cnt; i++) {
>> +      clear_obj(&lockstack_start[i]);
>> +    }
>> +  }
>> +  set_lockstack_size(0);
>> +  set_has_lockstack(false);
>> +}
>> +
>>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>>    if (*((juint*)this) == badHeapWordVal) {
>>      st->print_cr("BAD WORD");
>> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
>> index 28e0576801e..928e94dd695 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.hpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
>> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>>  
>>    void copy_lo...
>
> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.

It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811903902
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811900946

From dholmes at openjdk.org  Wed Oct 23 05:52:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 05:52:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

Thanks for those updates.

src/hotspot/share/runtime/objectMonitor.hpp line 299:

> 297:   // Simply set _owner field to new_value; current value must match old_value.
> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 299:   // Same as above but uses tid of current as new value.

By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
> 302:   void      set_owner_from_BasicLock(JavaThread* current);

Shouldn't tid there be the basicLock?

src/hotspot/share/runtime/objectMonitor.hpp line 334:

> 332: 
> 333:   // Returns true if BasicLock* stored in _stack_locker
> 334:   // points to current's stack, false othwerwise.

Suggestion:

  // points to current's stack, false otherwise.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377

From aboldtch at openjdk.org  Wed Oct 23 05:59:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 23 Oct 2024 05:59:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
Message-ID: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>

On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
>> 
>>> 5339: 
>>> 5340: void MacroAssembler::inc_held_monitor_count() {
>>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>> 
>> Suggestion:
>> 
>> // Clobbers: rscratch1 and rscratch2
>> void MacroAssembler::inc_held_monitor_count() {
>>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>
> Also, is it better to have this without assignment.  Which is a nit.
> Address dst(rthread, JavaThread::held_monitor_count_offset());

The `=` in a variable definition is always construction, never assignment. 

That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811925424

From dholmes at openjdk.org  Wed Oct 23 06:10:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:10:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <seUf308yeihkninXEfoUFLIvtrKa_1hd-bC_qntyIt4=.d4465069-c13c-4e78-aaa1-09a66d87b2cc@github.com>
Message-ID: <7tG1N819A95VfA37K3PK5PejcHkaBPHzWdO6wGA06w0=.10223953-863f-4ca6-ae1b-085112085c3d@github.com>

On Wed, 23 Oct 2024 00:35:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 292:
>> 
>>> 290: 
>>> 291:   static int64_t owner_for(JavaThread* thread);
>>> 292:   static int64_t owner_for_oop(oop vthread);
>> 
>> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?
>
> I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

I like the idea of using `owner_id_from` but it then suggests to me that `JavaThread::_lock_id` should be something like `JavaThread::_monitor_owner_id`. 

The use of `tid` in comments can be confusing when applied to a `JavaThread` as the "tid" there would normally be a reference of its `osThread()->thread_id()" not it's `threadObj()->thread_id()`. I don't have an obviously better suggestion though.

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 
>> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.
>
> I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

old_tid/new_tid works for me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087

From dholmes at openjdk.org  Wed Oct 23 06:14:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:14:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>

On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
>> 
>>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>>> 114:      *   WAITING -> WAITED         // waiting on monitor
>>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
>> 
>> Waiting to re-enter the monitor?
>
> yes

Okay so should it say that?

>> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
>> 
>>> 176:     // timed-wait support
>>> 177:     private long waitTimeout;
>>> 178:     private byte timedWaitNonce;
>> 
>> Strange name - what does this mean?
>
> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

Suggestion: `timedWaitCounter` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604

From dholmes at openjdk.org  Wed Oct 23 06:18:17 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 23 Oct 2024 06:18:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

> The tid is cached in the JavaThread object under _lock_id. It is set on JavaThread creation and changed on mount/unmount.

Why do we need to cache it? Is it the implicit barriers related to accessing the `threadObj` oop each time?

Keeping this value up-to-date is a part I find quite confusing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707

From syan at openjdk.org  Wed Oct 23 06:52:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Oct 2024 06:52:10 GMT
Subject: RFR: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY [v2]
In-Reply-To: <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
 <uCEMRFWoaq8gT7vdCMlzilHcBxw7lLIFGFij-BCKJtQ=.45c0b7f7-70d2-43c6-8550-f29e1c76d86e@github.com>
Message-ID: <IYzHT0LbVxtjKgB95ao8hi5RrYD73OTpx1MRetwJwhE=.176f96e7-1a34-495a-8c17-c2ab7e629519@github.com>

On Mon, 21 Oct 2024 13:12:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
>> 
>> So the below test command will print error:
>> 
>> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
>> 
>> 
>> Building target 'test' in configuration 'linux-x86_64-server-release'
>> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
>> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
>> RunTests.gmk:206: *** Cannot continue. Stop.
>> 
>> 
>> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JTREG="TEST_THREAD_FACTORY=Virtual"
>  - Use JTREG="JTREG_TEST_THREAD_FACTORY=Virtual" to make comment more cleaner

Thanks all for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21594#issuecomment-2431064891

From syan at openjdk.org  Wed Oct 23 06:52:11 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 23 Oct 2024 06:52:11 GMT
Subject: Integrated: 8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be
 TEST_THREAD_FACTORY
In-Reply-To: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
References: <1oDFeWVzfHyuEjjHh0zG1KB4spHUKxKTmDAVnW5mUc0=.d0ee985a-2493-46c0-a3f9-d7f9b2d0e6c7@github.com>
Message-ID: <TtJHGCMWxZRvsjYdNwBL8zUZkPKHLOF1zg5tr9xNnDQ=.c40af807-38c6-4d18-9476-89600d15fba9@github.com>

On Sun, 20 Oct 2024 02:11:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> In [make/RunTests.gmk](https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L208), the keyword is 'TEST_THREAD_FACTORY'.
> 
> So the below test command will print error:
> 
> make test TEST=test/jdk/java/math/BigInteger/TestValueExact.java CONF=linux-x86_64-server-release JTREG="JTREG_TEST_THREAD_FACTORY=Virtual"
> 
> 
> Building target 'test' in configuration 'linux-x86_64-server-release'
> JTREG_TEST_THREAD_FACTORY=Virtual is not a valid keyword for JTREG.
> Valid keywords: JOBS TIMEOUT_FACTOR FAILURE_HANDLER_TIMEOUT TEST_MODE ASSERT VERBOSE RETAIN TEST_THREAD_FACTORY MAX_MEM RUN_PROBLEM_LISTS RETRY_COUNT REPEAT_COUNT MAX_OUTPUT REPORT OPTIONS JAVA_OPTIONS VM_OPTIONS KEYWORDS EXTRA_PROBLEM_LISTS LAUNCHER_OPTIONS.
> RunTests.gmk:206: *** Cannot continue. Stop.
> 
> 
> So I think we should fix the document bug in `doc/testing.md` to avoid take the same mistake. Trivial fix, no risk.

This pull request has now been integrated.

Changeset: cdad7286
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cdad7286c6a099f5d0aa1f936e6201df9f3004cb
Stats:     5 lines in 4 files changed: 0 ins; 0 del; 5 mod

8342646: JTREG_TEST_THREAD_FACTORY in testing.md should be TEST_THREAD_FACTORY

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/21594

From alanb at openjdk.org  Wed Oct 23 07:27:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 07:27:15 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v8]
In-Reply-To: <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>
Message-ID: <ak89_CLmtt00JS8ZiVpHDo8cAihMalDuWRZvTuu1YLQ=.0ef6c740-02ef-4659-8d52-b762961d6b18@github.com>

On Tue, 22 Oct 2024 19:16:21 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge
>  - review: explain better what methods can be annotated with JvmtiMountTransition
>  - review: clarify the use of annotation @JvmtiMountTransition in yield/yield0
>  - review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller
>  - review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames
>  - Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>  - review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two
>  - fix one more place with trailing spaces
>  - fix trailing spaces
>  - add new test coverage with  vthread/CheckHiddenFrames
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d6eddcda...54dc2b4a

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 32:

> 30: /**
> 31:  * A method may be annotated as "jvmti mount transition" to hint
> 32:  * it is desirable to omit it from JVMTI stack traces.

Might be better to replace both usages of "jvmti mount transition" with JvmtiMountTransition.

"virtual thread mount state transition (VTMS transition)" should probably be "Virtual Thread Mount State (VTMS) transition".

The updated wording is better but I think this still hard to audit to know if you've got the usages in the right place. Maybe we can re-visit it in the future.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2387552132
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1812046832

From alanb at openjdk.org  Wed Oct 23 09:56:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 09:56:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
Message-ID: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>

On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
>> 
>> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).
>
> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091

From rrich at openjdk.org  Wed Oct 23 09:56:12 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 23 Oct 2024 09:56:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
Message-ID: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>

On Wed, 23 Oct 2024 00:35:06 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's comments to ObjectMonitor.hpp

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value.
> 166:   int64_t _lock_id;

Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293

From alanb at openjdk.org  Wed Oct 23 10:01:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:01:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
Message-ID: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>

On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value.
>> 166:   int64_t _lock_id;
> 
> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812385061

From alanb at openjdk.org  Wed Oct 23 10:04:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:04:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.df72d7c2-f9a1-431d-984d-2b99febcbed2@github.com>

On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/javaThread.cpp line 2002:
> 
>> 2000: #ifdef SUPPORT_MONITOR_COUNT
>> 2001: 
>> 2002: #ifdef LOOM_MONITOR_SUPPORT
> 
> If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

LOOM_MONITOR_SUPPORT was only needed when there were ports missing. All 4 are included now so this goes away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812389702

From alanb at openjdk.org  Wed Oct 23 10:09:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 10:09:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.9a8bc4f3-d791-4c4b-be81-2b84c2813ef0@github.com>
Message-ID: <ekXIc0jjx_4MlD-GhPzW5S5LA4GARcY2WSXvLmnRl04=.3cc80103-51c0-476b-ac36-9568f0b5cb53@github.com>

On Tue, 22 Oct 2024 15:23:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

There's nothing exposed today to allow custom schedulers. The experiments/explorations going on right now have to be careful to not hold any locks. Throwing if holding a monitor is an option but only it would need to be backed by spec and would also shine light on the issue of j.u.concurrent locks as a carrier might independently hold a lock there too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431600434

From alanb at openjdk.org  Wed Oct 23 11:35:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:35:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
Message-ID: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>

On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.
>
> Suggestion: `timedWaitCounter` ?

We could rename it to timedWaitSeqNo if needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648

From stefank at openjdk.org  Wed Oct 23 11:43:27 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Oct 2024 11:43:27 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <pYI-64nT97A6U0xwVDOjKoXN4YKAJ3iNzxXFRDRd9Ss=.7334a043-2f5d-40e9-ba20-5bfb2266a4f2@github.com>

On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Avoid assert/endless-loop in JFR code

I've published an upstream PR for the SA bug:
https://github.com/openjdk/jdk/pull/21662

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2431837874

From stefank at openjdk.org  Wed Oct 23 11:44:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Oct 2024 11:44:38 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about TLAB
 layout
Message-ID: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>

When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.

The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".

When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:


"Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
 - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
 - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
 - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
 - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
 - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
 - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
 - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
 - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)

Locked ownable synchronizers:
    - None


It should be saying:

Locked ownable synchronizers:
    - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)


The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.

I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.

This is a reproducer of the problem:

make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"


I've tested this by running all 'serviceability' tests in our tier1-9 testing.

-------------

Commit messages:
 - 8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout

Changes: https://git.openjdk.org/jdk/pull/21662/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342857
  Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

PR: https://git.openjdk.org/jdk/pull/21662

From alanb at openjdk.org  Wed Oct 23 11:52:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:52:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <X1zMyNxr1gQDtqGLnw_Rv1DeJ-4IQcvPxY20Eb8SNoU=.5bdfb6e7-0f93-4289-b7aa-d7da4c67d004@github.com>
 <60NR4UYtz57FWH8yTBMSS5SPQVOGpXcoZ-9AP7o9y14=.6eb65796-4e30-4093-866d-226334d9977c@github.com>
Message-ID: <EEdxqnOAo9_wdmwyW4F-nsSKR-G1K_Lgy-TQHEfPB74=.38278323-1010-4b56-955e-4ad3fe4b0c91@github.com>

On Mon, 21 Oct 2024 17:20:15 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > There are a couple of micro benchmarks in test/micro that fork with `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be examined.
> 
> Fixed, will be in next drop. There are a couple of other micro tests that test the performance of `AccessController.doPrivileged` and `getContext` which probably don't make sense anymore, but I've left them for now to be looked at later.

I checked the commit in the sandbox and it looks okay. It may be some future maintenance in these micros may do some pruning as aren't too useful now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2431865182

From alanb at openjdk.org  Wed Oct 23 11:57:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 11:57:31 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:

> 340:         throws Exception
> 341:     {
> 342:         action.run();

testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812582305

From alanb at openjdk.org  Wed Oct 23 12:01:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>

On Tue, 22 Oct 2024 21:20:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
> 
>> 31:  * @test
>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
> 
> line 36 can also be removed.
> 
> 
> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest

hasSM and the code that only runs when true can be deleted too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812587449

From alanb at openjdk.org  Wed Oct 23 12:17:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:17:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:

> 239:         Properties props = System.getProperties();
> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
> 241:         System.setSecurityManager(new SecurityMan());

I assume SecurityMan should be removed too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812614134

From coleenp at openjdk.org  Wed Oct 23 12:47:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:47:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/hotspot/share/prims/jvm.cpp line 1272:

> 1270: 
> 1271: 
> 1272: // Returns the inherited_access_control_context field of the running thread.

There's some code in this file in 
static void trace_class_resolution_impl(Klass* to_class, TRAPS) {

That does this:


    while (!vfst.at_end()) {
      Method* m = vfst.method();
      if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
          !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
          !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
        break;
      }
      last_caller = m;
      vfst.next();
    }


Is this dead code that should be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812677985

From alanb at openjdk.org  Wed Oct 23 12:56:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 23 Oct 2024 12:56:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
Message-ID: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>

On Wed, 23 Oct 2024 12:44:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/hotspot/share/prims/jvm.cpp line 1272:
> 
>> 1270: 
>> 1271: 
>> 1272: // Returns the inherited_access_control_context field of the running thread.
> 
> There's some code in this file in 
> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
> 
> That does this:
> 
> 
>     while (!vfst.at_end()) {
>       Method* m = vfst.method();
>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>         break;
>       }
>       last_caller = m;
>       vfst.next();
>     }
> 
> 
> Is this dead code that should be removed?

This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812694528

From rkennke at openjdk.org  Wed Oct 23 13:03:19 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 23 Oct 2024 13:03:19 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
Message-ID: <rnihqvTSvTSVvQ-B_BekpovR9Si1fw-gjiY-zGziFMs=.09961e51-9651-4067-9da0-f0c8f2dc60fb@github.com>

On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8342560: GenShen: Fix confusing method name
>    
>    Reviewed-by: ysr
>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>    
>    Reviewed-by: xpeng, ysr
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>    
>    Reviewed-by: kdnilsen, ysr
>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>    
>    Reviewed-by: ysr
>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>    
>    Reviewed-by: ysr
>  - 8342255: GenShen: Remove unnecessary enum initial values
>    
>    Reviewed-by: ysr
>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408

I've looked at the changes again, especially at all that changed since my last full review. It's looking good to me, now. Please remove the one newline that I've spotted. Thanks for this work, this is really a huge effort!

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 1:

> 1: 

This newline is one too much.

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2388573425
PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1812694226

From rkennke at openjdk.org  Wed Oct 23 13:07:04 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 23 Oct 2024 13:07:04 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <NOrA3MPYZrM8l75vf7PtWdwvot1Jw9jRwETHEmbJ5e0=.437c78a2-4d34-4b9c-b416-3c8db2681ff8@github.com>

On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

The changes make sense to me and the code now matches the C++ implementation on HotSpot. Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2388617960

From dfuchs at openjdk.org  Wed Oct 23 13:10:37 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 23 Oct 2024 13:10:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
Message-ID: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>

On Wed, 23 Oct 2024 11:54:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
> 
>> 340:         throws Exception
>> 341:     {
>> 342:         action.run();
> 
> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?

Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1812727202

From rsunderbabu at openjdk.org  Wed Oct 23 14:07:49 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 23 Oct 2024 14:07:49 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v2]
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <kHKCWXZCM04eCgvkFXTLlkK8D-M41pfs5CRhdldFWww=.3ef64644-5012-486b-bbda-7561a5c27e03@github.com>

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  use single compile, reuse utility class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21641/files
  - new: https://git.openjdk.org/jdk/pull/21641/files/0826d40a..b3d9da8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=00-01

  Stats: 79 lines in 10 files changed: 17 ins; 38 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21641/head:pull/21641

PR: https://git.openjdk.org/jdk/pull/21641

From rsunderbabu at openjdk.org  Wed Oct 23 14:11:06 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 23 Oct 2024 14:11:06 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v2]
In-Reply-To: <kHKCWXZCM04eCgvkFXTLlkK8D-M41pfs5CRhdldFWww=.3ef64644-5012-486b-bbda-7561a5c27e03@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
 <kHKCWXZCM04eCgvkFXTLlkK8D-M41pfs5CRhdldFWww=.3ef64644-5012-486b-bbda-7561a5c27e03@github.com>
Message-ID: <whuRJvX_QTWBbOVR_etg1V3pkNSMK8PTZdlc_tHqp8M=.2cc31737-a412-42f8-8fb8-d32e19b79f60@github.com>

On Wed, 23 Oct 2024 14:07:49 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
>> 
>> Testing done for
>> Tiers 1,2,3
>> test/hotspot/jtreg tests
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use single compile, reuse utility class

Changes
1. Replace batch compile to single compile wherever applicable.
2. Reuse utility classes in the merged InMemoryJavaCompiler, remove unused utility class

PS: batch compile cannot be removed as certain use cases need it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21641#issuecomment-2432334700

From lmesnik at openjdk.org  Wed Oct 23 15:48:06 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 23 Oct 2024 15:48:06 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <Vp9hhG1x6E2_opVbRhURo9VazsuuPGtKD5MwKdus0tA=.5c86413b-f0d2-4a88-a93f-8664a531c641@github.com>

On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2389260656

From weijun at openjdk.org  Wed Oct 23 16:44:12 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 23 Oct 2024 16:44:12 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <vkFXDrfqmjr7DCBmg3owJbqmXtyLTT-caPh4uAoP6e8=.49c1ee9d-6a70-4686-9e67-b761a1a1da38@github.com>

On Mon, 21 Oct 2024 14:34:30 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

The `security.cpp` looks fine to me. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2432824930

From cjplummer at openjdk.org  Wed Oct 23 16:50:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 16:50:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
Message-ID: <E-Bf06aA-4rDKiEguZePf70RDhRM2y0cJbc0BFunkfg=.174159ca-f410-4035-9c77-d98dd6088d09@github.com>

On Wed, 23 Oct 2024 05:23:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 53:
>> 
>>> 51: #ifndef _WIN32
>>> 52: static MUTEX_T my_mutex = MUTEX_INIT;
>>> 53: #endif
>> 
>> The reason for no reference on windows is because of the following on windows:
>> 
>> 
>> #define MUTEX_LOCK(x)           /* FIXUP? */
>> #define MUTEX_UNLOCK(x)         /* FIXUP? */
>> 
>> 
>> So looks like this mutex support is something we never got around to. I think your current workaround is fine.
>
> I'm curious now, how to implement mutex support on Windows? I think I prefer that to just making it completely unavailable on Windows

We've gone 20 years without it on Windows, so I'm inclined not to worry about the lack of support on Windows. Logging is not used often in the debug agent. I've turned in on once in a while but usually find it too noisy and hard to read. What I usually opt for is changing some of the log_message() calls to instead just use tty_message().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1813176284

From cjplummer at openjdk.org  Wed Oct 23 16:54:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 16:54:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
Message-ID: <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>

On Wed, 23 Oct 2024 05:22:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 47:
>> 
>>> 45: {
>>> 46:     void *mappedMemory;
>>> 47:  // HANDLE memHandle;
>> 
>> Why comment out this one but not the one at line 88? It seems they are both equally problematic and are hiding the static memHandle. I'm not sure why the 2nd one isn't flagged. I'd actually suggest getting rid of the static memHandle. It does not seem to be needed.
>
> I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead

I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1813181393

From pchilanomate at openjdk.org  Wed Oct 23 17:26:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Rename timedWaitNonce to timedWaitSeqNo
 - Fix comment in Thread.java
 - Clear oops when thawing lockstack + add thaw_lockstack()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/b6bc98e2..e232b7f3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04-05

  Stats: 77 lines in 5 files changed: 29 ins; 18 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <IhkGdT3usE5UZqOTAqS-hBQ2FE_2Lc_2pZK5hM_mkdg=.6ea43f0e-f158-414e-a675-ec9682fac8d8@github.com>

On Mon, 21 Oct 2024 12:32:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Rename timedWaitNonce to timedWaitSeqNo
>>  - Fix comment in Thread.java
>>  - Clear oops when thawing lockstack + add thaw_lockstack()
>
> src/hotspot/share/oops/stackChunkOop.cpp line 471:
> 
>> 469:     }
>> 470:   }
>> 471: }
> 
> Can we turn these three very similar loops into one? In my opinion, it is easier to parse.
> 
> ```C++
> void stackChunkOopDesc::copy_lockstack(oop* dst) {
>   const int cnt = lockstack_size();
>   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>   const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
>   const auto get_obj = [&](intptr_t* at) -> oop {
>     if (requires_gc_barriers) {
>       if (requires_uncompress) {
>         return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
>       }
>       return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
>     }
>     return *reinterpret_cast<oop*>(at);
>   };
> 
>   intptr_t* lockstack_start = start_address();
>   for (int i = 0; i < cnt; i++) {
>     oop mon_owner = get_obj(&lockstack_start[i]);
>     assert(oopDesc::is_oop(mon_owner), "not an oop");
>     dst[i] = mon_owner;
>   }
> }

Done. I combined it with the oop clearing suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417

From pchilanomate at openjdk.org  Wed Oct 23 17:26:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:26:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <wk7OwnHqWSnOUTM0kjKrCHtJnmS3EM-ApYS3NPWM4Q0=.a4653342-a642-465f-99de-2ebfc7ce3c49@github.com>
 <RulvKabvbAfeRDUrRwCyOWVgGcDBcBNYAM1Hx3W-u5E=.daa0cbb3-756c-4209-bb47-ceb64c0fc164@github.com>
 <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.8d34d892-31f1-4e0f-83cb-2693cae84b58@github.com>
Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.b256c1ad-c2d4-44e8-bc39-3201c5a29481@github.com>

On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?
>
> The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.
> 
> It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

I renamed it to transfer_lockstack() and applied the suggested version with the lambda.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813224287

From kizune at openjdk.org  Wed Oct 23 17:27:42 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 23 Oct 2024 17:27:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <cYDFZ0hXc_bXKTrCftDs1-Xd-Rr4iOpngFb3pB8zi2U=.6d408fe5-63bc-45a3-8ff4-264671975ed1@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

Finished reviewing of accessibility (both in com.sun and jdk.javax), jdk.javax.sound and jdk.java.awt.Desktop. Looks good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2432939145

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
Message-ID: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>

On Tue, 22 Oct 2024 07:03:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/share/runtime/threadIdentifier.cpp line 30:
> 
>> 28: 
>> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
>> 30: static const int64_t INITIAL_TID = 3;
> 
> Can we express this in terms of those reserved values, or are they inaccessible?

Yes, we could define a new public constant `static const int64_t FIRST_AVAILABLE_TID = 3` (or some similar name) and use it here:


diff --git a/src/hotspot/share/runtime/threadIdentifier.cpp b/src/hotspot/share/runtime/threadIdentifier.cpp
index 60d6a990779..710c3141768 100644
--- a/src/hotspot/share/runtime/threadIdentifier.cpp
+++ b/src/hotspot/share/runtime/threadIdentifier.cpp
@@ -24,15 +24,15 @@

 #include "precompiled.hpp"
 #include "runtime/atomic.hpp"
+#include "runtime/objectMonitor.hpp"
 #include "runtime/threadIdentifier.hpp"

-// starting at 3, excluding reserved values defined in ObjectMonitor.hpp
-static const int64_t INITIAL_TID = 3;
-static volatile int64_t next_thread_id = INITIAL_TID;
+// excluding reserved values defined in ObjectMonitor.hpp
+static volatile int64_t next_thread_id = ObjectMonitor::FIRST_AVAILABLE_TID;

 #ifdef ASSERT
 int64_t ThreadIdentifier::initial() {
-  return INITIAL_TID;
+  return ObjectMonitor::FIRST_AVAILABLE_TID;
 }
 #endif

Or maybe define it as MAX_RESERVED_TID instead, and here we would add one to it.

> src/java.base/share/classes/java/lang/Thread.java line 731:
> 
>> 729: 
>> 730:         if (attached && VM.initLevel() < 1) {
>> 731:             this.tid = 3;  // primordial thread
> 
> The comment before the `ThreadIdentifiers` class needs updating to account for this change.

Fixed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 109:
> 
>> 107:      *
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 
> Should this say something similar to the parked case, about the "yield" being successful?

Since the unmount is triggered from the VM we never call yieldContinuation(), unlike with the PARKING case. In other words, there are no two cases to handle. If freezing the continuation fails, the virtual thread will already block in the monitor code pinned to the carrier, so a state of BLOCKING means freezing the continuation succeeded.

> src/java.base/share/classes/java/lang/VirtualThread.java line 110:
> 
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 
> Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

It means it is scheduled to run again and re-contest for the monitor.

> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
> 
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
> 
> Presumably this one means it acquired the monitor?

Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239314
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239799
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240352

From pchilanomate at openjdk.org  Wed Oct 23 17:36:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 17:36:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <JXxI8EDULCkgrb7O42G2wH535prg_KtBtEnwGA3Y6rQ=.47ce4bdd-0c46-41fe-9430-df64663c6936@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.179301e3-42e6-4975-ad8f-9474eb73247a@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.c0fd4818-df37-4e55-9559-25c9b96dd64e@github.com>
Message-ID: <v_7OhzC9sq5rI3jGQjn-W8sPfuqFRlaFWPwvxylxDYM=.f3de1cfd-c8dc-4fbb-8a44-a08e4555905f@github.com>

On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Suggestion: `timedWaitCounter` ?
>
> We could rename it to timedWaitSeqNo if needed.

Ok, renamed to timedWaitSeqNo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667

From mdonovan at openjdk.org  Wed Oct 23 18:05:26 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 23 Oct 2024 18:05:26 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v3]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <eJLQogAxhuWS5YFaWbMrraUediMgzZiyW8YKp9eq-pc=.ba21749f-f1fb-4457-88a4-3fefc69d8c4b@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  fixed whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/83599700..7dbe83e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From honkar at openjdk.org  Wed Oct 23 18:06:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 18:06:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <-GbMPbwNI--hHPZyyPgdU-pOMZh0Z4tZ_tLdbv-LL2E=.1494bfd4-7941-4c2e-af9b-82a29a4b2427@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

@prsadhuk 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud

Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433031866

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <JIUHCHz_e9bimk2zFSrHyVmUgsVSwV_136nzCfPa3X8=.204dd87d-b744-47c2-8493-54772d05ddde@github.com>
Message-ID: <nTh2g7Sw6iv8lfDeUFsAru4vij3UTDzgCvhC8pwp3JU=.4546e9fb-99d9-48f9-8948-c6c1172355ea@github.com>

On Wed, 23 Oct 2024 05:11:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
>> @prsadhuk Addressed review comments in the following jep486 branch commit: [openjdk/jdk-sandbox at d9ee496](https://github.com/openjdk/jdk-sandbox/commit/d9ee496f7349cb8beaf1e696fd430f8064baee8e)
>> 
>>     1. test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java - Updated, removed redundant try-catch block
>> 
>>     2. test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - Repurposed and added back
>> 
>>     3. test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Updated, added finally block
>> 
>>     4. test/jdk/javax/swing/UIDefaults/6795356/TableTest.java - Added back
>> 
>> 
>> Left out comments that fall into out-of-scope/clean-up for jep486.
> 
> looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud..

> @prsadhuk
> 
> > looks ok but awt import should have been before swing as decided, although this again is not part of SM exercise but since you modified the tests I thought I will say it aloud
> 
> Thanks! I didn't notice it happened again with the new changes. This was probably due to IDE settings. Since this was a recent change I have updated in the latest commit.

I also didn't realise you had "changed" it. I'm finding it very painful to navigate to the related files in this huge PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433046255

From prr at openjdk.org  Wed Oct 23 18:14:35 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 23 Oct 2024 18:14:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <ZLiF5TADkOkZ9p142_bjFkSO5cM4DKmqd7j3mnJxnhs=.2d8f316d-a604-4f17-be07-1a917491d5b3@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

I've reviewed all jdk/java/awt and jdk/javax/imageio tests.
I've either commented or proactively fixed in the jep sandbox branch. Or both.
Next sync from there should resolve those.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433048411

From mdoerr at openjdk.org  Wed Oct 23 18:18:23 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 23 Oct 2024 18:18:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
Message-ID: <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>

On Tue, 22 Oct 2024 13:53:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I will do some benchmarks
>
> I did SpecJBB runs with shift of 6, 8 and 10, respectively, which amounts to Klass alignment of 64, 256 and 1K. Benchmark scores did not show a significant pattern. I did not measure CPU stats though. 
> 
> But I still think a dynamically calculated shift makes sense, and I hesitate to change this code at this point. I therefore would like to move this question to followup RFEs if necessary.

This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.
In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1813304646

From coleenp at openjdk.org  Wed Oct 23 19:18:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:18:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
Message-ID: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>

On Wed, 23 Oct 2024 12:53:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 1272:
>> 
>>> 1270: 
>>> 1271: 
>>> 1272: // Returns the inherited_access_control_context field of the running thread.
>> 
>> There's some code in this file in 
>> static void trace_class_resolution_impl(Klass* to_class, TRAPS) {
>> 
>> That does this:
>> 
>> 
>>     while (!vfst.at_end()) {
>>       Method* m = vfst.method();
>>       if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())&&
>>           !vfst.method()->method_holder()->is_subclass_of(access_controller_klass) &&
>>           !vfst.method()->method_holder()->is_subclass_of(privileged_action_klass)) {
>>         break;
>>       }
>>       last_caller = m;
>>       vfst.next();
>>     }
>> 
>> 
>> Is this dead code that should be removed?
>
> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.

but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813400810

From coleenp at openjdk.org  Wed Oct 23 19:25:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 19:25:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <_gXXCttW-h4AfQUaeBanzH40dfndZS9GIBzqHQ6ob-8=.0ea3c533-9cdc-4fc4-aa7d-0debff0a97a5@github.com>
Message-ID: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.30bd0702-7c5b-4806-babe-fc33027928b9@github.com>

On Wed, 23 Oct 2024 06:15:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why do we need to cache it? Is it the implicit barriers related to accessing the threadObj oop each time?

We cache threadObj.thread_id in JavaThread::_lock_id so that the fast path c2_MacroAssembler code has one less load and code to find the offset of java.lang.Thread.threadId in the code.  Also, yes, we were worried about performance of the barrier in this path.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605

From egahlin at openjdk.org  Wed Oct 23 19:31:26 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Oct 2024 19:31:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <kg1P7IgX_T7-UHKt5vu-cy5LgmEGCF6DXQskxCjsMPo=.fd01234b-ac4d-48ce-97df-01acd1c1fa7d@github.com>

On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Avoid assert/endless-loop in JFR code

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2389952721

From egahlin at openjdk.org  Wed Oct 23 19:31:26 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Oct 2024 19:31:26 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
 <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <Dfb8NRaKopl215q7WQ68VBR4axwO7_dNTle1TCdZPZ0=.70d2d9bd-f0b0-431c-a472-f1e7f2ecfca5@github.com>

On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.

JFR changes look reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2433263488

From honkar at openjdk.org  Wed Oct 23 19:41:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 19:41:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
Message-ID: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>

On Mon, 21 Oct 2024 21:12:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
> 
>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>> 75: 
>> 76:         if (args.length > 1) {
> 
> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
> 
> Also the messing around with exceptions at the end of the test is pointless

@prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.

Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2

I'll be rename the test as suggested when I update this test next.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813429265

From cjplummer at openjdk.org  Wed Oct 23 19:51:11 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 23 Oct 2024 19:51:11 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>

On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Changes requested by cjplummer (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:

> 441: 
> 442:        Type collectedHeap = db.lookupType("CollectedHeap");
> 443:        CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");

I think you can use getSizet() here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2390075171
PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1813440444

From honkar at openjdk.org  Wed Oct 23 20:20:35 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 23 Oct 2024 20:20:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <0hopUxCsiLaaoyBfNaj3hnNsGq-at7ttBqERS6OfGLI=.280f52c2-d171-455e-aefd-a983fe33e0cf@github.com>
 <N4TPFWjvqPoNF5GoMy7_wizATYMJRkhF2JAT4Or9fLs=.eb574b68-32ef-44a7-8b9e-8e39d4d96e9a@github.com>
Message-ID: <vmkpLn9nL1RxwBDfE6plkj6ja6Ks2R7_V355BH4mVGQ=.8b4c1433-acd9-4180-9169-5997f934125b@github.com>

On Wed, 23 Oct 2024 19:38:10 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/CachePremissionsTest/CachePermissionsTest.java line 76:
>> 
>>> 74:         System.out.println("java.io.tmpdir is " + System.getProperty("java.io.tmpdir"));
>>> 75: 
>>> 76:         if (args.length > 1) {
>> 
>> The isFileCacheExpected logic does not make sense. The test sets set to use the cache but then reads whether to expect it based on the args[0]. If that were set to false  the test will fail. So why is it there ?
>> 
>> Also the messing around with exceptions at the end of the test is pointless
>
> @prrace I might have missed removing this check which was in the original test. The latest update to this test has two run tags but it fails when isFileCacheExpected is set to true.
> 
> Did you mean to keep only one run tag? https://github.com/openjdk/jdk-sandbox/commit/1bf77a393c5756bca65760402077617d37be72d2
> 
> I'll be rename the test as suggested when I update this test next.

No changes required for this test. The test was failing due to IDE config issue of tmp dir.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813474346

From pchilanomate at openjdk.org  Wed Oct 23 20:22:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:22:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/e232b7f3..baf7ffab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=05-06

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 23 20:47:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <miLC8LKnqW0hiJjo-1USKNalZp-YgtPg6l1F9opS3-c=.7e1afcf2-0c1b-465d-83fd-d4ed0457dc88@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.228dea0b-c886-42b4-888b-01abec9e503e@github.com>
 <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.222ddc32-fb89-4144-bc81-57d6d096637f@github.com>
Message-ID: <gGm48Cxs1mgNeICqJxSkVYxDdT4gGogR9QP6rIcrDVQ=.093b0c5a-ffbe-44b0-b75b-d480321490b1@github.com>

On Tue, 22 Oct 2024 15:56:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
>> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.
>
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
> 
> Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

I see we are already using rscratch1 in these locking macros so I could change it to use that instead. But looking at all other macros in this file we are already using rscratch1 and rscratch2 too, so I think we would be fine either way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813513144

From pchilanomate at openjdk.org  Wed Oct 23 20:47:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.cf07eea4-baca-4af5-9f58-a1580c1c839c@github.com>
 <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.a169c90d-8431-4b49-b7b4-a1029bdf6ac2@github.com>
Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.849e94b4-6aa7-4035-9304-525109dbba4c@github.com>

On Wed, 23 Oct 2024 05:56:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Also, is it better to have this without assignment.  Which is a nit.
>> Address dst(rthread, JavaThread::held_monitor_count_offset());
>
> The `=` in a variable definition is always construction, never assignment. 
> 
> That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

Added comment and fixed dst definition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813514402

From pchilanomate at openjdk.org  Wed Oct 23 20:47:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <kH2u40WKvMqwAH-7OfA6M7rLcJCqE2P_ICMpsngk0ds=.988ded3b-8f0c-4054-af50-7ed20c3066bd@github.com>
Message-ID: <1fIoKFEkaZWw0x3eG4cdDbHX_RVga-A6ovBsZnwVgbk=.bc2d26c6-c9a2-4ebe-9e95-9bf9733b947c@github.com>

On Wed, 23 Oct 2024 00:19:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:
> 
>> 5352:   str(rscratch2, dst);
>> 5353:   Label ok;
>> 5354:   tbz(rscratch2, 63, ok);
> 
> 63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

I can remove the check. I don't think it hurts either though. Also we can actually just use rscratch1 in the ASSERT case.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:
> 
>> 229: 
>> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
>> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());
> 
> Address dst(xthread, JavaThread::held_monitor_count_offset());

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648

From pchilanomate at openjdk.org  Wed Oct 23 20:47:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <lhvvZyPmUnCSAdQgpRg6Mmzk3r8B3OxC3-3PHo9J7e8=.b81a8fa5-5094-40c6-8eb1-e71dba39ba32@github.com>
Message-ID: <FmKOCSsujrPLhOUfXlnZeAeUrWiLQLMmseBgvHuWrsA=.fcdb55a8-3bde-407a-a26f-b8515ab7407a@github.com>

On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Fix comments in objectMonitor.hpp
>>  - Move frame::saved_thread_address() to platform dependent files
>>  - Fix typo in jvmtiExport.cpp
>>  - remove usage of frame::metadata_words in possibly_adjust_frame()
>>  - Fix comments in c2 locking paths
>>  - Revert and simplify changes to c1_Runtime1 on aarch64 and riscv
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:
> 
>> 5355: 
>> 5356: void MacroAssembler::dec_held_monitor_count() {
>> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::dec_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813515113

From pchilanomate at openjdk.org  Wed Oct 23 20:47:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>

On Wed, 23 Oct 2024 05:42:34 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:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/objectMonitor.hpp line 299:
> 
>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 299:   // Same as above but uses tid of current as new value.
> 
> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449

From pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
Message-ID: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>

On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.
>
> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
> 
> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.

[1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450

From pchilanomate at openjdk.org  Wed Oct 23 20:47:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 23 Oct 2024 20:47:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
Message-ID: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>

On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
>> 
>> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
> 
> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846

From mullan at openjdk.org  Wed Oct 23 21:57:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 21:57:34 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
Message-ID: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>

On Wed, 23 Oct 2024 12:14:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
> 
>> 239:         Properties props = System.getProperties();
>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>> 241:         System.setSecurityManager(new SecurityMan());
> 
> I assume SecurityMan should be removed too.

Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1813724467

From mullan at openjdk.org  Wed Oct 23 22:21:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 23 Oct 2024 22:21:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <-WUk0E4MRJ1CB84NKT6g7L3pmv-IFpgTnJsrjsjSavA=.53352f0c-6c82-4a45-86c8-b3468c842d9e@github.com>

On Tue, 22 Oct 2024 21:36:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Reviewed test/jdk/java/lang/** and test/jdk/sun/reflect/* tests.

Thanks for the comprehensive review. I have incorporated all of your comments except for removing the enum from `java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java` which is a bit more involved. I plan on posting an updated PR with these and other changes tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2433572062

From duke at openjdk.org  Wed Oct 23 23:01:10 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 23 Oct 2024 23:01:10 GMT
Subject: RFR: 8341482: Attach API access to /proc filesystem should use
 doPrivileged [v2]
In-Reply-To: <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
 <Jp9oVnxZ7ikCUab8f4OsQ_1VMHTiUGabcvgEUlc8bTM=.aa8a3d40-5025-4412-9b3f-e0d090bcdcfd@github.com>
Message-ID: <qog9cWeJ674jZcXnK5mLOSUy4h_sFq-OUE_5p98FhGo=.db1adf9a-6271-45b8-9d9e-cf272ff4cc11@github.com>

On Wed, 2 Oct 2024 21:15:11 GMT, Larry Cable <duke at openjdk.org> wrote:

>> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
>> 
>> to resolve an issue detected in: 
>> 
>> https://bugs.openjdk.org/browse/JDK-8341246
>> 
>> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8327114: fix to resolve permissions issue as per: 8341246, also privileged exists and isReadable invocations

closed superceded by 8342449

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21312#issuecomment-2433694112

From duke at openjdk.org  Wed Oct 23 23:01:11 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 23 Oct 2024 23:01:11 GMT
Subject: Withdrawn: 8341482: Attach API access to /proc filesystem should use
 doPrivileged
In-Reply-To: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
References: <2AUSpzO22hPJ82syTcfyrb8NhzZuYAet-MbcvgDfWQM=.2df12e78-79f5-4dbe-b8ee-8ff144d38516@github.com>
Message-ID: <lIupif9wyAZzDbRMh0HtTKu7za6IRj_IR6GfNwipmcY=.5ca0731e-99c1-4171-a14f-60bb56f16fde@github.com>

On Wed, 2 Oct 2024 19:55:29 GMT, Larry Cable <duke at openjdk.org> wrote:

> this is a fix to: https://bugs.openjdk.org/browse/JDK-8327114 
> 
> to resolve an issue detected in: 
> 
> https://bugs.openjdk.org/browse/JDK-8341246
> 
> /proc/**/* file accesses should be performed as "privileged" actions to avoid security mgr exceptions.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21312

From amenkov at openjdk.org  Thu Oct 24 01:48:38 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 01:48:38 GMT
Subject: RFR: 8342577: Clean up JVMTI breakpoint support
Message-ID: <JbSsksMFRTSKodRSJKPZVM99HM84BeAzpK4LqKFWPmY=.f276d4f4-a79c-40db-a86a-20cd6722ca86@github.com>

The fix cleans up code to support list of JVMTI breakpoints.
- classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped;
- class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code;
- fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637);
- JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor;
- JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass;

Testing: tier1..tier6

-------------

Commit messages:
 - bp_cleanup

Changes: https://git.openjdk.org/jdk/pull/21675/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21675&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342577
  Stats: 352 lines in 2 files changed: 27 ins; 284 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/21675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21675/head:pull/21675

PR: https://git.openjdk.org/jdk/pull/21675

From iklam at openjdk.org  Thu Oct 24 03:01:54 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 24 Oct 2024 03:01:54 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:

 - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
 - disable test that fails with hotspot_runtime_non_cds_mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/1b6c3e28..dd59b5f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=02-03

  Stats: 103 lines in 4 files changed: 100 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From jwaters at openjdk.org  Thu Oct 24 03:36:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 03:36:04 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>

On Mon, 21 Oct 2024 14:34:30 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

Thanks Weijun for the ok on security (Though it still makes me uneasy because it smells like a bug, but I guess it's alright). I haven't pushed yet to remove the changes to the other files in this Pull Request because the way I did it I'd have to force push and that would destroy all the review comments, I'll do that once the comments have been fully addressed

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434176106

From jwaters at openjdk.org  Thu Oct 24 03:36:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 03:36:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
 <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
Message-ID: <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>

On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I wasn't sure whether the global memHandle not being used was a bug, so I commented out the local one. I missed the line 88 one because it wasn't flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.

Oh, I was referring to the static global one. In that case I'll remove it (Or rather, comment it so it isn't lost to time and someone can bring it back if need be)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1814187989

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.df75a887-c4f7-401c-a6ae-de3ce15528f7@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.a21f7ea8-f021-461d-a3ae-e6f7496cf345@github.com>
 <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.95a21d40-200c-464b-8fd7-f23dd3835e70@github.com>
Message-ID: <Q4NNfZ8Vuzy9966oDBrXA3pf4818J5MEL13_l_KLmzQ=.e1697634-4105-4bee-8d20-0a375fd190e8@github.com>

On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.
>
> It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

Pushed a fix to avoid printing the virtual thread tid if we hit that case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814186777

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <mNTnBIQU6ZIDBjhQG1gXilOvrXL6L2MFBIfWnj7z35w=.ac9ab654-5ded-4cd2-b030-7526795baea1@github.com>
 <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.2dc4489f-9a6b-4b4c-a96b-c2af4f70ae27@github.com>
Message-ID: <uhUjIm6NwTlveCt80zVVVMHSs2D2aVRo0oGpZfuiKyk=.6f63f256-5046-43ff-b2e1-49fd7602fffd@github.com>

On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 166:
>> 
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporary value.
>>> 166:   int64_t _lock_id;
>> 
>> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.
>
> Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

I extended the comment to mention this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814189388

From pchilanomate at openjdk.org  Thu Oct 24 03:38:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
Message-ID: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>

On Wed, 23 Oct 2024 05:43:53 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:
>> 
>>   Address David's comments to ObjectMonitor.hpp
>
> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
> 
> Shouldn't tid there be the basicLock?

So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

> src/hotspot/share/runtime/objectMonitor.hpp line 334:
> 
>> 332: 
>> 333:   // Returns true if BasicLock* stored in _stack_locker
>> 334:   // points to current's stack, false othwerwise.
> 
> Suggestion:
> 
>   // points to current's stack, false otherwise.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856

From pchilanomate at openjdk.org  Thu Oct 24 03:38:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 03:38:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix comment in objectMonitor.hpp and javaThread.hpp
 - Skip printing tid when not available

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/baf7ffab..03ba6dfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=06-07

  Stats: 23 lines in 4 files changed: 17 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From lmesnik at openjdk.org  Thu Oct 24 05:15:29 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 24 Oct 2024 05:15:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
Message-ID: <kIFHgHW4e-LKs1cklS5gCfulvfjqP8uEHm2fvQNDLJM=.6e53020e-50ff-484b-b0ba-626dccf75c10@github.com>

On Tue, 22 Oct 2024 16:19:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Avoid assert/endless-loop in JFR code

Not actually review, just confirming that my request fulfilled. And no more issues arised during PIT

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2391292083

From lmesnik at openjdk.org  Thu Oct 24 05:15:30 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 24 Oct 2024 05:15:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
 <YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>
Message-ID: <Q1kbjcs2NnrkL51fHs7B8y-Kyx-zVRor8ZKmRoXmXvw=.3ef65ffe-2edb-4640-874e-6b389926e12e@github.com>

On Fri, 30 Aug 2024 07:37:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> make/Images.gmk line 135:
>> 
>>> 133: #
>>> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
>>> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty
>> 
>> The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.
>
> No, zero works with +COH, but a small change is needed. I'll post a suggestion inline.

no objection anymore

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814259543

From jrose at openjdk.org  Thu Oct 24 05:46:08 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 05:46:08 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <6ESSOT5cMkoM_k1L32iXOAeYNLpjmeOlKPWZvYOVcc8=.c16e28d3-faee-444e-a37c-addc8e07bb54@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

I took a closer look at the diffs in a file you renamed, from `classPrelinker.cpp` to `aotConstantPoolResolver.cpp`.  Changes still look good, notably the filtering logic on the bootstrap methods (and their arguments) that we support.

For the record, the diff I made for review is enclosed.  It makes the new indy-related logic stand out pretty well.

[classPrelinker.deleted.cpp.txt](https://github.com/user-attachments/files/17501832/classPrelinker.deleted.cpp.txt)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2434351458

From dholmes at openjdk.org  Thu Oct 24 05:58:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/share/prims/jvm.cpp line 4012:

> 4010:     }
> 4011:     ThreadBlockInVM tbivm(THREAD);
> 4012:     parkEvent->park();

What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value. Also,
> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread

s/temporary change/temporarily change/

src/java.base/share/classes/java/lang/Object.java line 383:

> 381:             try {
> 382:                 wait0(timeoutMillis);
> 383:             } catch (InterruptedException e) {

I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622

From dholmes at openjdk.org  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
Message-ID: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>

On Wed, 23 Oct 2024 20:22:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv

src/java.base/share/classes/java/lang/Thread.java line 654:

> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread

Suggestion:

     * counter is off-heap and shared with the VM to allow it to assign thread

src/java.base/share/classes/java/lang/Thread.java line 655:

> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 655:      * identifiers to non-Java threads.

Why do non-JavaThreads need an identifier of this kind?

src/java.base/share/classes/java/lang/VirtualThread.java line 631:

> 629:         // Object.wait
> 630:         if (s == WAITING || s == TIMED_WAITING) {
> 631:             byte nonce;

Suggestion:

            byte seqNo;

src/java.base/share/classes/java/lang/VirtualThread.java line 948:

> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
> 947:      */
> 948:     private void waitTimeoutExpired(byte nounce) {

I assume you meant `nonce` here, but please change to `seqNo`.

src/java.base/share/classes/java/lang/VirtualThread.java line 952:

> 950:         for (;;) {
> 951:             boolean unblocked = false;
> 952:             synchronized (timedWaitLock()) {

Where is the overall design of the timed-wait protocol and it use of synchronization described?

src/java.base/share/classes/java/lang/VirtualThread.java line 1397:

> 1395: 
> 1396:     /**
> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.

Suggestion:

     * Returns a lock object for coordinating timed-wait setup and timeout handling.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814158735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814159210
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814169150
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814170953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814171503
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814172621

From dholmes at openjdk.org  Thu Oct 24 05:58:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
Message-ID: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>

On Wed, 23 Oct 2024 17:32:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
>> 
>>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
>> 
>> Presumably this one means it acquired the monitor?
>
> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:

RUNNING -> BLOCKING -> BLOCKED
BLOCKED -> UNBLOCKING -> RUNNABLE

I'm just trying to get a better sense of what we can infer if we see these "transition" states.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283

From dholmes at openjdk.org  Thu Oct 24 05:58:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 05:58:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>

On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
>> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
>> 
>> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491
>
>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>
> Yes.

I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814167842

From jrose at openjdk.org  Thu Oct 24 06:17:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 06:17:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <ZlzUKcGyjkJXpZ6IbaVy90ZnxVjFkEi0a-Uf0fLVov4=.c06e3163-4cdb-46f1-9499-a28a9fcef54c@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

A thought for a possible cleanup, after this PR is done?

The scratch mirror logic had me? scratching my head.  It seems to me that a more descriptive name would make the code explain itself better.  I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset").  This is in distinction to the current "live" mirror, which is also the AOT phase mirror.  In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term.  But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase).  In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure.

(When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else?  Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2434387290

From dholmes at openjdk.org  Thu Oct 24 06:21:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 06:21:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
Message-ID: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>

On Thu, 24 Oct 2024 03:31:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
>> 
>> Shouldn't tid there be the basicLock?
>
> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:

Before: owner = BasicLock* belonging to current
After: owner = JavaThread* of current

with the new version we have:

Before: owner = ANONYMOUS_OWNER
After: owner = tid of current

so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162

From cjplummer at openjdk.org  Thu Oct 24 06:56:10 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 06:56:10 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <Z7fEiWloCxVjeGyUyrdX_wwfw-aeEzMVhUcGiFLXzQU=.e428731f-7827-4dde-afda-d96f96d1b689@github.com>
 <YJgNMtsrtgWS6dFc60zAv57U4vlX7Vv6JiH6oMaI94c=.fea148c8-61c9-40bc-8d47-27b6ccc6cf1c@github.com>
 <PVYkac0hz2kZm06cfLm0wmoScou2H1ALnkUMLcGAW3s=.7ef6e0df-8950-4aa5-bb8f-bf1a33830221@github.com>
 <TtWY-ZqfMHIKg1LuPv0g5QiOA72gspX4swBV7x_mYaQ=.10226be1-eeff-4515-a01e-029d8ca1d861@github.com>
Message-ID: <whkGf16yIybHQHqDk0yqh_VxNdOn2hgHoaGm6IIXYqY=.a1448788-f01e-4309-af4c-0116d990a43f@github.com>

On Thu, 24 Oct 2024 03:31:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm not sure what you mean by "that one". It's the static one that should be removed. The local variables always hide the static, and there seems to be no reason for the value of memHandle to survive outside of the local scope it is used in.
>
> Oh, I was referring to the static global one. In that case I'll remove it (Or rather, comment it so it isn't lost to time and someone can bring it back if need be)

I would just remove the static. I don't see any reason for it to exist.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1814375764

From stooke at openjdk.org  Thu Oct 24 07:03:36 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Thu, 24 Oct 2024 07:03:36 GMT
Subject: RFR: 8319873: Add macOS implementation for jcmd System.map and
 System.dump_map
Message-ID: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@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.

[Sample output (with NMT enabled)](https://github.com/user-attachments/files/16968316/vm_memory_map_87218.txt)

-------------

Commit messages:
 - fix whitepsace errors
 - initial release
 - fix whitespace
 - more test cleanup
 - refactor System.dump test for MacOS
 - Merge branch 'master' into pr_macos_system_dump
 - add macOS to liast of supposredt platforms
 - Merge branch 'openjdk:master' into pr_macos_system_dump
 - fix macOS System.map tests
 - fix merge error
 - ... and 8 more: https://git.openjdk.org/jdk/compare/363327e6...c6628d30

Changes: https://git.openjdk.org/jdk/pull/20953/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319873
  Stats: 577 lines in 9 files changed: 499 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 alanb at openjdk.org  Thu Oct 24 07:06:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:06:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>

On Thu, 24 Oct 2024 02:42:35 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/Thread.java line 655:
> 
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
>> 655:      * identifiers to non-Java threads.
> 
> Why do non-JavaThreads need an identifier of this kind?

JFR. We haven't changed anything there, just the initial tid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940

From dholmes at openjdk.org  Thu Oct 24 07:14:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 07:14:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
Message-ID: <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>

On Thu, 24 Oct 2024 03:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> the way I did it I'd have to force push

That should not be the case. You can just anti-delta changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2434475849

From alanb at openjdk.org  Thu Oct 24 07:18:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:18:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
Message-ID: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>

On Wed, 23 Oct 2024 19:15:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This tracing skips ClassLoader frames, you'll continue to see these when using Class.forName.
>
> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.

Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814402940

From jrose at openjdk.org  Thu Oct 24 07:19:10 2024
From: jrose at openjdk.org (John R Rose)
Date: Thu, 24 Oct 2024 07:19:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <SdrXTg7ahkXiSffKdmpzKO9TbtgZ2_8MLEx-OAZJG8w=.96dd3105-3d00-4ad1-bf89-8b63d0753b81@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

I read it through again.  Some stylistic issues we have discussed can be saved for later.  I didn't find any new problems, and known old problems are addressed. Ship it!

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2391527792

From alanb at openjdk.org  Thu Oct 24 07:51:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 07:51:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <28R_1poNvjGMa9GI5z5mmudDS_3Kvzq9vJ_0sTpDJpA=.403c90e3-b158-4ccf-9875-7af3ad872d2c@github.com>

On Thu, 24 Oct 2024 05:54:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/prims/jvm.cpp line 4012:
> 
>> 4010:     }
>> 4011:     ThreadBlockInVM tbivm(THREAD);
>> 4012:     parkEvent->park();
> 
> What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

It's very similar to the "Reference Handler" thread. That thread calls into the VM to get the pending-Reference list. Now we have "VirtualThread-unblocker" calling into the VM to get the list of virtual threads to unblock. ObjectMonitor::ExitEpilog will the unpark this thread when the virtual thread successor is on the list to unblock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822

From stefank at openjdk.org  Thu Oct 24 08:11:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 08:11:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/share/runtime/objectMonitor.hpp line 325:

> 323:   }
> 324: 
> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814489387

From alanb at openjdk.org  Thu Oct 24 08:29:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 08:29:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>

On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
>
> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
> 
> RUNNING -> BLOCKING -> BLOCKED
> BLOCKED -> UNBLOCKING -> RUNNABLE
> 
> I'm just trying to get a better sense of what we can infer if we see these "transition" states.

We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084

From stefank at openjdk.org  Thu Oct 24 08:30:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 08:30:47 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v2]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <fHvk7yaB74M7pJnqE2-4ShK4DTyaA9Pjgu97aNvgbec=.e13801bd-ad0f-4d78-b660-6a3c6087d34f@github.com>

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant db.lookupType

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21662/files
  - new: https://git.openjdk.org/jdk/pull/21662/files/be690e24..e8ec2957

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

PR: https://git.openjdk.org/jdk/pull/21662

From sspitsyn at openjdk.org  Thu Oct 24 08:42:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 08:42:46 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v9]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <klIYtQeQbTc3LEMLI84UB5M8uvomzlp_HqufyzNth3Q=.ecd07139-fdd6-42ee-9bb0-b5d36c9e0023@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: remove jvmti annotation for yield methods; simplify frames hiding and events posting code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/54dc2b4a..58ab0057

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=07-08

  Stats: 59 lines in 5 files changed: 5 ins; 26 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Thu Oct 24 08:51:47 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 08:51:47 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v10]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: undo minor tweaks in a couple of continuation related files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/58ab0057..5d6e5c91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=08-09

  Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From stuefe at openjdk.org  Thu Oct 24 09:15:30 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 09:15:30 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
 <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
Message-ID: <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>

On Wed, 23 Oct 2024 18:14:50 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.

It's a bit late. We are close to pushing. While it should be harmless to drop below alignment to below cache line size, this would be a change affecting all platforms and would require all tests repeated. 

PPC/s390 are not targeted by the JEP. There had never been a discussion I am aware of that these platforms have to be clean with +COH. While it's nice that the changes had been contributed, I don't think that test errors on these platforms should hold up pushing this RFE. Therefore, if needed, we should just omit +COH part of the test for PPC/S390.

But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.

> In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.

?? The comment is correct. We try to avoid hyper alignment, hence we drop the shift to - if possible - log 2 cache line size. If it's equal to log 2 cache line size, we succeeded.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814598543

From alanb at openjdk.org  Thu Oct 24 09:22:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 09:22:14 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v10]
In-Reply-To: <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <GpAoGQeesqKsUPGRzWOoT_z5jP0J70ETrjilg-CPnvA=.ad5ef666-4e73-48a5-9d19-4cd036114d49@github.com>
Message-ID: <o3TsdTdUZMQ3IR05uoaRp8APe9E7cKWRl2NoTk91tZg=.ea1c4284-7095-4d9e-ace4-c3748579d015@github.com>

On Thu, 24 Oct 2024 08:51:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: undo minor tweaks in a couple of continuation related files

Latest update to JvmtiMountTransition looks okay. I assume wait until Alex Menkov and Leonid are finished their reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2434743507

From stuefe at openjdk.org  Thu Oct 24 09:25:35 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 09:25:35 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
 <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
 <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
 OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
Message-ID: <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>

On Thu, 24 Oct 2024 09:12:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.

that is the problem, test assumes log2 of 6 for chacheline size

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814617136

From amitkumar at openjdk.org  Thu Oct 24 09:31:31 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 24 Oct 2024 09:31:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
 <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
 <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
 OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
 <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
Message-ID: <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>

On Thu, 24 Oct 2024 09:22:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> This code causes test errors in `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test passes when we remove "s > log_cacheline && " from the condition below.
>> 
>> It's a bit late. We are close to pushing. While it should be harmless to drop below alignment to below cache line size, this would be a change affecting all platforms and would require all tests repeated. 
>> 
>> PPC/s390 are not targeted by the JEP. There had never been a discussion I am aware of that these platforms have to be clean with +COH. While it's nice that the changes had been contributed, I don't think that test errors on these platforms should hold up pushing this RFE. Therefore, if needed, we should just omit +COH part of the test for PPC/S390.
>> 
>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
>> 
>>> In addition, it doesn't fit to the comment which claims we should avoid shifts larger than the cacheline size. This enforces shifts to be larger (or equal to) than the cacheline size.
>> 
>> ?? The comment is correct. We try to avoid hyper alignment, hence we drop the shift to - if possible - log 2 cache line size. If it's equal to log 2 cache line size, we succeeded.
>
>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
> 
> that is the problem, test assumes log2 of 6 for chacheline size

PPC log2 will be `7` (`DEFAULT_CACHE_LINE_SIZE? = 128`) and for S390x it will be `8` (`DEFAULT_CACHE_LINE_SIZE? = 256`). 

So I guess this change should be fine for now : 

diff --git a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
index e04e716315a..c1be59e77ab 100644
--- a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
+++ b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
@@ -108,7 +108,9 @@ public static void main(String[] args) throws Exception {
 
         long ccsSize = 128 * M;
         int expectedShift = 6;
-        test(forceAddress, true, ccsSize, forceAddress, expectedShift);
+        if (!Platform.isPPC() && !Platform.isS390x()) {
+            test(forceAddress, true, ccsSize, forceAddress, expectedShift);
+        }
 
         ccsSize = 512 * M;
         expectedShift = 8;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814627120

From amitkumar at openjdk.org  Thu Oct 24 09:46:31 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 24 Oct 2024 09:46:31 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
 <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <ISW5WbcZr7Rr8Zg462H--apDVxKgiDKzVWGlXfhlgek=.2ea3202f-29e6-47f1-987c-52e11add973d@github.com>

On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright
>>  - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.

@rkennke Please include s390x implementation from here: https://github.com/offamitkumar/jdk/commit/e67e332ce6b3b09e723c08b11146ebe0cc16f0fd. 

This also disables this test on s390x & PPC for now, but if that's not what we want then I can revert changes done to `CompressedClassPointersEncodingScheme.java` file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2434795830

From azvegint at openjdk.org  Thu Oct 24 09:56:37 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 24 Oct 2024 09:56:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <HoUuHVqcGME8iweQAWbnP6igoSGpoRtK7oX32sXi7fk=.a7ec909b-aa58-477f-bf1a-a9244a49df12@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

java beans changes looks good

-------------

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2391943640

From mdoerr at openjdk.org  Thu Oct 24 09:57:41 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 24 Oct 2024 09:57:41 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
 <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
 <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
 OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
 <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
 <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
Message-ID: <EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>

On Thu, 24 Oct 2024 09:28:13 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>>> But then, what exactly is the error? If it's just the test assuming that cache line size is log 6, then the test should be fixed for ppc, not hotspot.
>> 
>> that is the problem, test assumes log2 of 6 for chacheline size
>
> PPC log2 will be `7` (`DEFAULT_CACHE_LINE_SIZE? = 128`) and for S390x it will be `8` (`DEFAULT_CACHE_LINE_SIZE? = 256`). 
> 
> So I guess this change should be fine for now : 
> 
> diff --git a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> index e04e716315a..c1be59e77ab 100644
> --- a/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> +++ b/test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java
> @@ -108,7 +108,9 @@ public static void main(String[] args) throws Exception {
>  
>          long ccsSize = 128 * M;
>          int expectedShift = 6;
> -        test(forceAddress, true, ccsSize, forceAddress, expectedShift);
> +        if (!Platform.isPPC() && !Platform.isS390x()) {
> +            test(forceAddress, true, ccsSize, forceAddress, expectedShift);
> +        }
>  
>          ccsSize = 512 * M;
>          expectedShift = 8;

As I understand the comment, it says alignment <= cache line size. But the implementation makes alignment >= cache line size. "hyper alignment" means alignment > cache line size?
If we want alignment = cache line size, I'll be ok with disabling the +COH part of the test on PPC64 and s390. Correct, the problem is that the test assumes that log cache line size = 6.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814666149

From stuefe at openjdk.org  Thu Oct 24 10:05:29 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 24 Oct 2024 10:05:29 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v21]
In-Reply-To: <EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TCFshDmOrJjN0zTh1X9BGEa_rczyMqRbyDIiYsFr_5I=.ea051371-4c86-461e-8721-83b32caf808f@github.com>
 <qPL-XuWVkfNYFmfYatyQZwbHismNzW_jXdvkDvIiVNc=.d4fd26a8-f509-494a-bd3d-0c6f37ba5269@github.com>
 <spymZDxJXwseFGxL78zfn4V8qe9NpX3gifTgd_eQkiM=.d1af7cf3-b503-4c35-93bb-db00f3c4cfc8@github.com>
 <U1HQ2ijNoadMNlrW_Adxkju4fM8kfAB4hn-a_gkPrnA=.7e0fee38-8534-4dcc-8aac-77d6559687c8@github.com>
 <CNrcAK8SrGCzsreT3SdoxaoGaqKqGb989t-waCJUz64=.0662bccb-661f-4dc9-b8b6-24d615035261@github.com>
 <YyPrYu-6p5wcUwfMQQamwoM1eGp6eUze_yC1lrc7mb0=.f1e5853b-3b6e-4460-8f57-a6f7588e513e@github.com>
 <Na5LWOz_h0ZGmLcETAxDA9wYiEopgWfvNTbYAELExR8=.e30fe7a0-c766-4bb4-aebb-fc6643c832c1@github.com>
 <0fDctIMZlpNZ4a5_idrN_w8KnvGfPS49Bw_9WRdjJ9I=.8bedb8be-0b33-468b-b711-9c0b4fb6649e@github.com>
 <G2EVWD7HifRRUclJtjvBIZS7CdwuYg4HlUH9QyXMLCw=.b9ff7725-2d53-4ae8-94ee-cb32c3bf1dfa@github.com>
 <vMlI9KnBvvHNvxT__7149la64QKN1CrHlr3
 OoX17x-E=.e06e392f-0e55-465d-b33e-a69d7f6ba5b3@github.com>
 <cQxx13f6ujrDdrDqN_ynyMHKAEOJsKWwPpNDs3da_Mo=.d2fcfe0c-77d1-4e9c-8022-d103fd91fa0c@github.com>
 <XuC0_RaUpR0_JvlEzq8-j7oqovvyqNHFQyWPmDQamqA=.a5e8730c-555a-4872-919b-c39fa0873f97@github.com>
 <EhhpOu63Iz3L0zJ24gmprx32GB024wOfF8dYejNwtBY=.95d2a304-9033-4fe0-9f20-939608451b9e@github.com>
Message-ID: <jukDFOOSL9NVHA-RzXo6E9nhIV66vCf0lVnBtqu73ug=.ea8a5277-c7d3-4eb0-84b0-55960e4f3d38@github.com>

On Thu, 24 Oct 2024 09:54:05 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> As I understand the comment, it says alignment <= cache line size. But the implementation makes alignment >= cache line size. "hyper alignment" means alignment > cache line size?

Correct. since encoding range must cover the full klass range, and we only have 22bit nklass, shift is larger. at most 10. but since that causes hyper aligning, we try to get away with smaller shifts if klass range is smaller.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1814680330

From coleenp at openjdk.org  Thu Oct 24 11:35:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 11:35:35 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
Message-ID: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>

On Thu, 24 Oct 2024 07:15:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> but you won't see access_controller_klass or priviledged_action_klass frames, so no need to skip them?  Not sure why you'd want to skip class loader frames here.
>
> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?

So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1814801818

From jpai at openjdk.org  Thu Oct 24 11:42:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 11:42:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

Hello Hans, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814810579

From hannesw at openjdk.org  Thu Oct 24 12:17:41 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:41 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright header

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21637/files
  - new: https://git.openjdk.org/jdk/pull/21637/files/70c1d49f..65a3ddf8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21637&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21637/head:pull/21637

PR: https://git.openjdk.org/jdk/pull/21637

From hannesw at openjdk.org  Thu Oct 24 12:17:42 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 24 Oct 2024 12:17:42 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <22AsTwbSfv2tI3gWZYFc7kLSr6Ehs8MY2N8TkTsImFI=.6b5d7853-5a13-4270-b0a5-b00c562085f0@github.com>
Message-ID: <1SSi_dzz13sxXuDmlLMHn26DDwxozHVqmzIJkon1kFA=.6ce6f3c6-1e8e-4606-87ae-2ba61302c71e@github.com>

On Thu, 24 Oct 2024 11:39:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright header
>
> src/java.xml/share/classes/javax/xml/validation/SchemaFactoryConfigurationError.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Hello Hannes, this looks like an oversight - the copyright year update should have retained the 2013 and additionally introduced 2024.

Thanks for catching this, @jaikiran!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21637#discussion_r1814857072

From stefank at openjdk.org  Thu Oct 24 12:19:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 12:19:19 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v3]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <QXV17HiekS1EfuDq0OXD0LZa5x2-a0tU2BHatDnZ1qE=.2c0d5871-cec0-42dc-9834-ed0717cef8da@github.com>

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Remove redundant db.lookupType"
  
  This reverts commit e8ec2957d43730560c73e2ea9b3ec7a91fc25535.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21662/files
  - new: https://git.openjdk.org/jdk/pull/21662/files/e8ec2957..3f50944e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

PR: https://git.openjdk.org/jdk/pull/21662

From stefank at openjdk.org  Thu Oct 24 12:19:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 12:19:19 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v3]
In-Reply-To: <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
Message-ID: <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>

On Wed, 23 Oct 2024 19:48:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Remove redundant db.lookupType"
>>   
>>   This reverts commit e8ec2957d43730560c73e2ea9b3ec7a91fc25535.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:
> 
>> 441: 
>> 442:        Type collectedHeap = db.lookupType("CollectedHeap");
>> 443:        CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");
> 
> I think you can use getSizet() here.

`getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1814862338

From kevinw at openjdk.org  Thu Oct 24 12:24:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Oct 2024 12:24:09 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
Message-ID: <Yra0rgzl1ty8taFZeoqb7w5uDLJHiqA3uss2Zk7Tr4U=.33e359d6-067a-4403-94c9-a99a98a9bc06@github.com>

On Tue, 15 Oct 2024 22:31:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated comment
>  - feedback

src/hotspot/share/services/attachListener.hpp line 65:

> 63: /*
> 64: Version 1 (since jdk6): attach operations always have 3 (AttachOparation::arg_count_max)
> 65:   arguments, each up to 1024 (AttachOparation::arg_length_max) symbols.

"AttachOparation" typo and also "symbols" is clarified to mean characters in a review comment, so should probably change that here and also in attachListener.cpp 626, 627.
CompatTest.java says "1024 symbols"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1814869880

From kevinw at openjdk.org  Thu Oct 24 12:40:06 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Oct 2024 12:40:06 GMT
Subject: RFR: 8339289: Parameter size mismatch between client and VM sides
 of the Attach API - Windows [v4]
In-Reply-To: <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
Message-ID: <8s-LyB3ap55T8sIZX7dI_xw_OUwrWEp6MpNn3rCqbJk=.50e31782-d82a-470d-9f3c-664fc32f9ed0@github.com>

On Tue, 15 Oct 2024 22:31:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated comment
>  - feedback

src/hotspot/share/services/attachListener.cpp line 406:

> 404:   { "printflag",        print_flag },
> 405:   { "jcmd",             jcmd },
> 406:   { "getVersion",       get_version },

It's a bit of a nit, but "dumpheap" and other existing commands never use caps but the new "getVersion" does?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1814896928

From jpai at openjdk.org  Thu Oct 24 12:44:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 24 Oct 2024 12:44:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I2kDmWqE6Ca4VnWeVBXIT1oJTaBgT114GEuazR0do34=.3228f83c-9b8e-4af5-938d-08baed53bfe4@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

This doc-only change which merely reorders the `@param` tags looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392367946

From mullan at openjdk.org  Thu Oct 24 13:19:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 13:19:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge
 - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
 - Remove println about Security Manager.
 - Remove unused static variable NEW_PROXY_IN_PKG.
 - Remove static variable `DEFAULT_POLICY` and unused imports.
 - Remove hasSM() method and code that calls it, and remove comment about
   running test manually with SM.
 - clientlibs: import order
 - warning-string
 - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
 - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=02
  Stats: 65432 lines in 1867 files changed: 1137 ins; 60545 del; 3750 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From rkennke at openjdk.org  Thu Oct 24 14:05:40 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 14:05:40 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v51]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1ef6394d..aadd7b8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=50
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=49-50

  Stats: 16 lines in 1 file changed: 2 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <TAjuG-LLpFQjYHfC-K2h0rAynZrqV0ckIViIVvwJB94=.cb21f1de-39bc-4fb6-96a1-861834ccb336@github.com>

On Mon, 21 Oct 2024 22:51:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java line 31:
> 
>> 29:  * @summary test that all fields returned by getDeclaredFields() can be
>> 30:  *          set accessible if the right permission is granted; this test
>> 31:  *          also verifies that Class.classLoader final private field is
> 
> "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d8564fa8dd003456b6e313c5e07809999c7d96e1

> test/jdk/java/lang/StackWalker/CallerSensitiveMethod/csm/jdk/test/CallerSensitiveTest.java line 45:
> 
>> 43: 
>> 44:     public static void main(String... args) throws Throwable {
>> 45:         System.err.println("Test without security manager.");
> 
> Security manager is not relevant any more.  Suggest to drop this println.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/002276450e625b66b786fb7eae7256bbcafa7496

> test/jdk/java/lang/reflect/Proxy/nonPublicProxy/NonPublicProxyClass.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     private static final String NEW_PROXY_IN_PKG = "newProxyInPackage.";
> 
> This constant is no longer needed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/3dbf684263a75470b85a95b9446a44ceb99c4b3a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815057352
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058036
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815055982

From mullan at openjdk.org  Thu Oct 24 14:07:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 14:07:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
 <B_m8Rxsu69Z7n4ooJsFuW2HAuXzaVTh3e4j42Qy-XYU=.ec1bbd4e-402d-4d33-83c2-768c140f768f@github.com>
Message-ID: <ZHPRQ0q6AkTrdGKCsX_9xghixEQm8e0qe7UTbqPSCFM=.b57001b8-376f-4e00-9953-64d8bdaeb160@github.com>

On Wed, 23 Oct 2024 11:58:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/RevealDirectTest.java line 33:
>> 
>>> 31:  * @test
>>> 32:  * @summary verify Lookup.revealDirect on a variety of input handles, with security manager
>>> 33:  * @run main/othervm/policy=jtreg.security.policy/secure=java.lang.SecurityManager -ea -esa test.java.lang.invoke.RevealDirectTest
>> 
>> line 36 can also be removed.
>> 
>> 
>> * $ $JAVA8X_HOME/bin/java -cp $JUNIT4_JAR:../../../.. -ea -esa -Djava.security.manager test.java.lang.invoke.RevealDirectTest
>
> hasSM and the code that only runs when true can be deleted too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/559934662119b1372fd831de8be7c97f877e0947

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815058738

From rkennke at openjdk.org  Thu Oct 24 14:19:11 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 14:19:11 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v52]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <cjjVE9UklTmD7ofyudyMkhY9MWtD2MGmtPpZczGgm6w=.62f0f8eb-6c63-4ac2-8bcd-30d23240e989@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  s390 port

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/aadd7b8e..c2f6d202

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=50-51

  Stats: 151 lines in 9 files changed: 113 ins; 17 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From jwaters at openjdk.org  Thu Oct 24 14:22:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 14:22:28 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>

> 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8342682

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/e149e654..2294b27f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=00-01

  Stats: 68 lines in 22 files changed: 1 ins; 21 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From jwaters at openjdk.org  Thu Oct 24 14:22:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 24 Oct 2024 14:22:29 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage
In-Reply-To: <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <6bgDWzW7hPhgXiKPtf691dw78Fywzz7xpNfI7AixFsM=.ebc2cc90-ebc1-4187-ae38-3f0979a97dc9@github.com>
 <PAXJ4c957eITw8vYHeZk2eDQ6T60wVqOAJwpa_2I344=.1eef170c-5296-47ce-b0d3-aee9124834af@github.com>
Message-ID: <7TiLoi4kpEVA782sZ5phBa38PuZxf7Ny6H_lZ27cFgA=.59b35424-72f8-4cb8-be83-758c2e181836@github.com>

On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > the way I did it I'd have to force push
> 
> That should not be the case. You can just anti-delta changes.

I did it in a really inefficient way, by checking out all files except for the files that I wanted to stay. I could not figure out how to undo it. In any case, I'm sorry for the sin I just committed...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2435429996

From alanb at openjdk.org  Thu Oct 24 14:29:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 24 Oct 2024 14:29:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <icmgWhjNfiLqExpne0gm1f7djo1crFeJnz0QjQUixOk=.9251bc23-f4d8-49aa-b311-91d74fe76ece@github.com>
 <DTaMa9O4kKKsBJjGGZJWa_fo3vl4bNcIQMNvCo5vdFk=.920c9ac7-2d19-4bdc-ac0b-a57abe20345e@github.com>
 <zSlb5qt7dQuihKJF7TweXf8l6uXxMIAVIQ_XOzpebKY=.77cc5a73-72b6-4380-a3fe-b9faf78bf514@github.com>
 <WtUR6JZi-kMa-igTmbVQTChGCx9ydNuRaVYlBNqjyRI=.92cd5c32-dbe4-41d4-aa5d-63987d52d7ee@github.com>
 <Ya-AJX_YwvxXSvEkvtyHEwQNQBhCdPkADAQfu66rERw=.135dde81-aff5-4054-82f4-e46c09486799@github.com>
Message-ID: <bLyF3XGfyhUtiuOuG0jqnqZtXM0UgzNtZAAZhDyNymM=.cdec18a4-ba4e-4e32-918a-93be3d95fadc@github.com>

On Thu, 24 Oct 2024 11:32:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Right, although you might have to wait until there is more cleanup in the JDK code before they disappear completely. To clarify, most uses of privileged actions are only done when a SecurityManager is set but there some cases where they execute unconditionally. In the Class/ClassLoader then I think they are done conditionally so you should be okay. Are there tests for `-Xlog:class+resolve=debug` that would fail if we had a bug in this tracing code?
>
> So you're saying there will still be these frames in the stack that we want to skip?  Okay, we'll clean all that out later then.

I have the changes to Class/ClassLoader to propose as soon as this JEP integrates. If that can go in quickly then it would remove any concerns in advance of your cleanup to remove the filtering of these frames (although I don't think there is an issue as this code path is conditional based on whether a SM is set).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815107403

From iris at openjdk.org  Thu Oct 24 14:48:08 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 24 Oct 2024 14:48:08 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <I0JNrzns6q4kroyAUrklR25TtDu-NaMGivmDom9qvPg=.5a85ad97-a410-4e92-b509-b959420cd0ba@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Confirmed changes only re-order @param declarations.
 
Recommend @JoeWang-Java to review changes to java.xml since portions of that module are maintained in an upstream repository.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2392918255

From sspitsyn at openjdk.org  Thu Oct 24 14:52:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 24 Oct 2024 14:52:27 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: removed asserts from continuationFreezeThaw.cpp again

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/5d6e5c91..bc056ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From joehw at openjdk.org  Thu Oct 24 16:40:06 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 24 Oct 2024 16:40:06 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <uMoFOQDA3ikNwrePol8zee2hd4FO8lGqoeMFhVh70B4=.4407fe29-37bd-4a2c-9d51-0bfdb6cfb55b@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks Iris for the reminder. Changes to java.xml look good.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393208720

From heidinga at openjdk.org  Thu Oct 24 17:12:13 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 24 Oct 2024 17:12:13 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v3]
In-Reply-To: <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <aEW1gzlt54nr-O9B236ddY5FzO8X1JUr0IjIKGqgOuU=.729b1434-35ac-4427-8648-bf7a520fd487@github.com>
Message-ID: <3_QqIqOqw7Zhq-gpwFG72w4EWyoDfjNEHhdBt-eOjDU=.59d15b7a-9081-4cce-9303-108901d931c9@github.com>

On Wed, 23 Oct 2024 04:46:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fixed test failure with "jtreg -Dtest.dynamic.cds.archive=true ..."
>  - simplified the archiving of cpCache::resolved_references() -- we rely on AOTConstantPoolResolver::is_indy_resolution_deterministic() to do the filtering before indys are linked; there is no need to try to undo the resolved_references afterwards
>  - Fixed bug where the BSM oops for resolved indies are not archived

Looks good!

src/hotspot/share/cds/aotClassLinker.cpp line 156:

> 154:         ResourceMark rm;
> 155:         log_warning(cds, aot, link)("%s cannot be aot-linked because it nest host is not aot-linked", ik->external_name());
> 156:         return false;

This is a good find!  Just to note - the same kind of check isn't required for PermittedSubclasses as the class granting permission to be a subclass is necessarily already loaded as one of our supers.

-------------

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2390446370
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1815035125

From aivanov at openjdk.org  Thu Oct 24 17:26:47 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:26:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/java/awt/Desktop.java line 713:

> 711:      * {@code Info.plist}.
> 712:      *
> 713:      * @param printFileHandler handler

Suggestion:

     * @param printFileHandler handler
     *

Can we add a blank line here? It's present in the methods above.

Although there are other places below where it's missing; so not worth worrying.

src/java.desktop/share/classes/java/awt/Font.java line 1612:

> 1610:      * obtained.  The {@code String} value of this property is then
> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}

Suggestion:

     * specification of {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1613:

> 1611:      * interpreted as a {@code Font} object according to the
> 1612:      * specification of {@code Font.decode(String)}
> 1613:      * If the specified property is not found then null is returned instead.

Suggestion:

     * If the specified property is not found, null is returned instead.

The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

src/java.desktop/share/classes/java/awt/Font.java line 1780:

> 1778:      * <p>
> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}

Suggestion:

     * {@code Font.decode(String)}.

Period is missing.

src/java.desktop/share/classes/java/awt/Font.java line 1781:

> 1779:      * The property value should be one of the forms accepted by
> 1780:      * {@code Font.decode(String)}
> 1781:      * If the specified property is not found then the {@code font}

Suggestion:

     * If the specified property is not found, the {@code font}

src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:

> 66:      * @throws SecurityException if a security manager exists and its
> 67:      *            {@code checkPermission} method doesn't allow the operation
> 68:      * @see       GraphicsConfiguration

Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

src/java.desktop/share/classes/java/beans/Expression.java line 1:

> 1: /*

Needs copyright year update.

src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:

> 69:      *
> 70:      * @param targetType   the class object of the type to be edited
> 71:      * @param editorClass  the class object of the editor classs

Suggestion:

     * @param editorClass  the class object of the editor class

Typo with an extra ?s?. The line should remain unchanged.

src/java.desktop/share/classes/javax/swing/JTable.java line 6343:

> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
> 6342:      *                           returns <code>true</code>
> 6343:      *          method disallows this thread from creating a print job request

Suggestion:


One more line to remove here.

src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:

> 1: /*

Needs updating the copyright year.

test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:

> 26:   @key headful
> 27:   @bug       6785058
> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.

Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:

> 1: /*

Copyright year needs updating.

test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31:

> 29:  * @library ..
> 30:  * @run main Test7084904
> 31:  * @author Sergey Malenkov

The test below `Test4683761.java` removes the `@author` tag. Should it be removed here?

test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:

> 1: /*

Copyright years need updating.

test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:

> 27:  * @test
> 28:  * @bug 8060027
> 29:  * @run main/othervm ReferenceToNonStaticField

Other tests in the set removed `/othervm`. Is it left intentionally?

test/jdk/java/beans/XMLEncoder/Test4631471.java line 28:

> 26:  * @bug 4631471 6972468
> 27:  * @summary Tests DefaultTreeModel encoding
> 28:  * @run main/othervm Test4631471

Other tests in the set removed `/othervm`. Is it left intentionally?

Looks like this question applies to all tests in `XMLEncoder/` directory.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2392963469
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815168399
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815180719
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815184053
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815185648
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815187240
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815203856
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815290263
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815294333
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815320927
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815330072
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815362826
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815404801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815414445
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815434082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815439684
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815440669

From aivanov at openjdk.org  Thu Oct 24 17:30:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 17:30:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
Message-ID: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>

On Wed, 23 Oct 2024 02:56:30 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Agreed. This is not a "clean up / update tests" task.
>> If it is a change on some lines of code that are updated by the SM changes, then that's fair game, but otherwise only the SM behaviour is part of this task.
>> Anything that is not needed to be changed for that purpose, can (and mostly should) be left alone.
>
> I know this is not relevant to SM and would not have pointed it out had it not been modified in the PR..
> In some tests as I am going to point out below, the order is changed intentionally even though it does not have anything to do with SM, all I am asking it to restore it back in those tests (and since it will look odd to have different order in different tests, I generalize it all for all javax_swing tests in this PR which is what I reviewed)

> I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...

Did we agree on that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815457993

From honkar at openjdk.org  Thu Oct 24 18:01:47 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:01:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>

On Thu, 24 Oct 2024 17:16:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/beans/XMLEncoder/ReferenceToNonStaticField.java line 29:
> 
>> 27:  * @test
>> 28:  * @bug 8060027
>> 29:  * @run main/othervm ReferenceToNonStaticField
> 
> Other tests in the set removed `/othervm`. Is it left intentionally?

@aivanov-jdk 
It was missed when -Djava.security.manager=allow was removed. 
Out of curiosity: does it affect the performance of CI testing if tests are run in `/othervm` mode when it is not needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815499279

From honkar at openjdk.org  Thu Oct 24 18:12:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 18:12:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>

On Thu, 24 Oct 2024 14:55:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
> 
>> 711:      * {@code Info.plist}.
>> 712:      *
>> 713:      * @param printFileHandler handler
> 
> Suggestion:
> 
>      * @param printFileHandler handler
>      *
> 
> Can we add a blank line here? It's present in the methods above.
> 
> Although there are other places below where it's missing; so not worth worrying.

@seanjmullan Can you please advice on some of these src file javadoc related clean-up review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815510916

From cjplummer at openjdk.org  Thu Oct 24 18:17:06 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 18:17:06 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v3]
In-Reply-To: <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
 <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
Message-ID: <QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>

On Thu, 24 Oct 2024 12:16:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 443:
>> 
>>> 441: 
>>> 442:        Type collectedHeap = db.lookupType("CollectedHeap");
>>> 443:        CIntegerType sizeType = (CIntegerType) db.lookupType("size_t");
>> 
>> I think you can use getSizet() here.
>
> `getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.

It looks like `sizetType` is initialized further down in the constructor. You could move that up (and the other 6 types also) or move your new code down. And speaking of the new code, it is misplaced in the try block. Both the comment for that block and the exception thrown have to do with getting the version. The `reserveForAllocationPrefetch` code just above is also misplaced for the same reason. That got added by [JDK-8004710](https://bugs.openjdk.org/browse/JDK-8004710). Perhaps some cleanup is in order here. I don't think a try/catch/throw is needed for the tlab code. There are other places in the constructor that can throw an exception, and if that happens, it should be obvious from the stack trace where it happened. That is all you need to debug the issue. I think maybe the VMVersion section was special cased since it is the most likely failure point if something is really wrong that will result in a failure of SA to startup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1815517050

From rriggs at openjdk.org  Thu Oct 24 18:30:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:30:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.base/share/classes/java/io/FilePermission.java line 71:

> 69:  *
> 70:  * @apiNote
> 71:  * This permission cannot be used for controlling access to resources anymore

The word "anymore" is unnecessary.

src/java.base/share/classes/java/io/SerializablePermission.java line 40:

> 38:  *
> 39:  * @apiNote
> 40:  * This permission cannot be used for controlling access to resources anymore

Unnecessary "anymore"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811333130
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1811338244

From rriggs at openjdk.org  Thu Oct 24 18:37:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 18:37:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VA3UBNF0DdjO74Rrso2lte1eqJeZC9DZwmKL2I1B90Y=.4c2c6725-8995-42eb-96fb-439f20f6a4c3@github.com>
 <TI3ugFCQDopt5NdtdSuVeHu5_aLA8DS6sZmsjn-ON6E=.d864cfe6-1716-4d66-89cb-666b6c8c1cac@github.com>
Message-ID: <WP5Y8HfjmKGYOHZjnGID9Uj3_RcqBwlETVZqhbyLuoY=.b97320ba-8fa4-4ee6-bbeb-4fd9178bc3e8@github.com>

On Wed, 23 Oct 2024 21:54:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 241:
>> 
>>> 239:         Properties props = System.getProperties();
>>> 240:         props.setProperty(JDK_LANG_PROCESS_ALLOW_AMBIGUOUS_COMMANDS, "");
>>> 241:         System.setSecurityManager(new SecurityMan());
>> 
>> I assume SecurityMan should be removed too.
>
> Yes, and the comments that say "no SM" should be updated. @RogerRiggs can you take a look at this? Thanks.

Fix to ExecCommand pushed to the sandbox.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815540092

From amenkov at openjdk.org  Thu Oct 24 18:58:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 18:58:26 GMT
Subject: RFR: 8339289: Enhance Attach API to support arbitrary length
 arguments - Windows [v5]
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <iWv7pZoVkaW9evjBzWCjW_xgBi11cpSCP-WMChm-A6A=.2e182ba2-71db-4149-897b-196e84d99f50@github.com>

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:

 - renamed getVersion command
 - typos

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20782/files
  - new: https://git.openjdk.org/jdk/pull/20782/files/86bd1cd2..9e6a34e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20782&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20782&range=03-04

  Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20782.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20782/head:pull/20782

PR: https://git.openjdk.org/jdk/pull/20782

From amenkov at openjdk.org  Thu Oct 24 18:58:26 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 18:58:26 GMT
Subject: RFR: 8339289: Enhance Attach API to support arbitrary length
 arguments - Windows [v4]
In-Reply-To: <8s-LyB3ap55T8sIZX7dI_xw_OUwrWEp6MpNn3rCqbJk=.50e31782-d82a-470d-9f3c-664fc32f9ed0@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <hVCMjOMUizGIQMFiLgHsATHYLVbvBEiPddBiUZYV7Y0=.c58060eb-026f-4755-977e-a218ddd1a779@github.com>
 <8s-LyB3ap55T8sIZX7dI_xw_OUwrWEp6MpNn3rCqbJk=.50e31782-d82a-470d-9f3c-664fc32f9ed0@github.com>
Message-ID: <nhgvP-kj05l7adLOKaYJWuNzzaGbaemMN8OdXbdnJtk=.a2ec2d5a-7046-4225-a029-9d4d487540e8@github.com>

On Thu, 24 Oct 2024 12:37:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated comment
>>  - feedback
>
> src/hotspot/share/services/attachListener.cpp line 406:
> 
>> 404:   { "printflag",        print_flag },
>> 405:   { "jcmd",             jcmd },
>> 406:   { "getVersion",       get_version },
> 
> It's a bit of a nit, but "dumpheap" and other existing commands never use caps but the new "getVersion" does?

We have "agentProperties" command, but this is the only exception.
Renamed to "getversion".

> src/hotspot/share/services/attachListener.hpp line 65:
> 
>> 63: /*
>> 64: Version 1 (since jdk6): attach operations always have 3 (AttachOparation::arg_count_max)
>> 65:   arguments, each up to 1024 (AttachOparation::arg_length_max) symbols.
> 
> "AttachOparation" typo and also "symbols" is clarified to mean characters in a review comment, so should probably change that here and also in attachListener.cpp 626, 627.
> CompatTest.java says "1024 symbols"

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1815562279
PR Review Comment: https://git.openjdk.org/jdk/pull/20782#discussion_r1815560165

From mli at openjdk.org  Thu Oct 24 19:01:36 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 24 Oct 2024 19:01:36 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v51]
In-Reply-To: <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
Message-ID: <6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>

On Thu, 24 Oct 2024 14:05:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test

test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 107:

> 105:         // the encoding range. We expect the encoding Base to start at the class space start - but to enforce that,
> 106:         // we choose a high address.
> 107:         if (Platform.isAArch64() || Platform.isX64()) {

@rkennke please also enable riscv for this test `CompressedClassPointersEncodingScheme.java`, it passed in my environment. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1815565554

From coleenp at openjdk.org  Thu Oct 24 19:03:15 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v6]
In-Reply-To: <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <oSLY61E5-9Z6Z_ErhaQsZSqp723Fz3Rw7yhbmQ-kvMU=.ae54c6a1-c0a9-48d0-9a08-c26321d3a441@github.com>
Message-ID: <uOEk1wWFaFw278TYc_e7vn63TD7Ym3upyk2Yh7RJIhA=.5f1d73df-e4d9-4220-aa30-5f825bd73bde@github.com>

On Wed, 23 Oct 2024 17:26:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Rename timedWaitNonce to timedWaitSeqNo
>  - Fix comment in Thread.java
>  - Clear oops when thawing lockstack + add thaw_lockstack()

Round 2.  There are a lot of very helpful comments in the new code to explain what it's doing but I have some requests for some more.  And some questions.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935

From coleenp at openjdk.org  Thu Oct 24 19:03:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 24 Oct 2024 19:03:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
Message-ID: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>

On Thu, 24 Oct 2024 03:38:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>  - Skip printing tid when not available

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Can you write a comment what this is doing briefly and why?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:

> 1548: #endif /* ASSERT */
> 1549: 
> 1550:   push_cont_fastpath();

One of the callers of this gives a clue what it does.

  __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about

Why do you do this here?  Oh please more comments...

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:

> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
> 2032:     __ push_cont_fastpath();

We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

src/hotspot/share/runtime/continuation.cpp line 89:

> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
> 88:       if (_target->has_async_exception_condition()) {
> 89:         _failed = false;

This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:

> 1273: 
> 1274:   if (caller.is_interpreted_frame()) {
> 1275:     _total_align_size += frame::align_wiggle;

Please put a comment here about frame align-wiggle.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:

> 1276:   }
> 1277: 
> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);

I also forgot what patch does.  Can you add a comment here too?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:

> 1550:   assert(!cont.is_empty(), "");
> 1551:   // This is done for the sake of the enterSpecial frame
> 1552:   StackWatermarkSet::after_unwind(thread);

Is there a new place for this StackWatermark code?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657:

> 1655: }
> 1656: 
> 1657: template<typename ConfigT, bool preempt>

This function is kind of big, do we really want it duplicated to pass preempt as a template parameter?

src/hotspot/share/runtime/objectMonitor.cpp line 876:

> 874:   // and in doing so avoid some transitions ...
> 875: 
> 876:   // For virtual threads that are pinned do a timed-park instead, to

I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

src/hotspot/share/runtime/objectMonitor.cpp line 2305:

> 2303: }
> 2304: 
> 2305: void ObjectMonitor::Initialize2() {

Can you put a comment why there's a second initialize function?  Presumably after some state is set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813899129
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814081166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814905064
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815015410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815016232
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815245735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815036910
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877

From stefank at openjdk.org  Thu Oct 24 19:09:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 19:09:42 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v4]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Cleanups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21662/files
  - new: https://git.openjdk.org/jdk/pull/21662/files/3f50944e..adc7d755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=02-03

  Stats: 41 lines in 1 file changed: 17 ins; 18 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

PR: https://git.openjdk.org/jdk/pull/21662

From stefank at openjdk.org  Thu Oct 24 19:09:42 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Oct 2024 19:09:42 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v4]
In-Reply-To: <QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <0_0LoiSECTe_JEfGgOTCICMw1lblyUhN0F7WSCE8GdA=.fc9c6013-657f-4eaa-9378-c1c51357e881@github.com>
 <hhk-fgIOWjo43mkZp_kiKVNAGWcRyB8U-dRNi9Hbz48=.8b2b451f-bfb3-46f7-b04a-3faaf17eb3b2@github.com>
 <QAkjnHtY_DGrtA4bBNUkm6DKES2xsgdHFXOeO4UjpHA=.774ac3fe-ee68-485f-b5dc-77ff9946ea72@github.com>
Message-ID: <RQ-ITSxYyU7Dry29P8-55SDilhHLn8tq0kAz5dtRLn4=.14b347e4-84a7-45d4-9851-d655e4a35ef8@github.com>

On Thu, 24 Oct 2024 18:14:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> `getSizet()` seems to be a function in `Flags`, so I don't see a direct way to use it. I could probably use the `sizetType` instead of `db.lookupType("size_t")`, however when I tested the tests failed because sizetType had not been initialized yet.
>
> It looks like `sizetType` is initialized further down in the constructor. You could move that up (and the other 6 types also) or move your new code down. And speaking of the new code, it is misplaced in the try block. Both the comment for that block and the exception thrown have to do with getting the version. The `reserveForAllocationPrefetch` code just above is also misplaced for the same reason. That got added by [JDK-8004710](https://bugs.openjdk.org/browse/JDK-8004710). Perhaps some cleanup is in order here. I don't think a try/catch/throw is needed for the tlab code. There are other places in the constructor that can throw an exception, and if that happens, it should be obvious from the stack trace where it happened. That is all you need to debug the issue. I think maybe the VMVersion section was special cased since it is the most likely failure point if something is really wrong that will result in a failure of SA to startup.

OK. I did some cleanups. Could you take a look and see if this is good enough to get this integrated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21662#discussion_r1815573383

From rriggs at openjdk.org  Thu Oct 24 19:23:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:23:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <u1-uOqM_jiV8EcaC7dsfCwCQiUjiQVcgHL2XfvTbXBg=.33981b17-c4df-435d-87fe-b552e2fabbb8@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.io... changes in classes and tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2436170029

From darcy at openjdk.org  Thu Oct 24 19:36:05 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 24 Oct 2024 19:36:05 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <C7bEaXoK5m7U1dx10KUM-56dwGBKOh0-x_vtV3T2dpg=.d6c51bc6-0a33-4568-8188-78de35125012@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Changes in java.compiler look fine.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21637#pullrequestreview-2393555695

From rriggs at openjdk.org  Thu Oct 24 19:43:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 19:43:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed rmi classes and tests
Reviewed ProcessBuilder, ProcessHandler, and Runtime.exec classes and tests

src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:

> 340:         /*
> 341:          * There is no security manager, so disable access to RMI class
> 342:          * loaders and use the would-de parent instead.

Fix typo "would-de" -> "would-be".

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2393555484
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815601635

From cjplummer at openjdk.org  Thu Oct 24 20:11:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 24 Oct 2024 20:11:05 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v4]
In-Reply-To: <o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <o-3eJ3A5yUNKkXc3AuUUX0zZ9_dsz512oxIv_IzlGNc=.818b9e08-7071-47ee-ab12-808458d65925@github.com>
Message-ID: <_0uHT4bd7SU4eAejzvRxbm-irb0pEHleXHvzrxjsXdU=.74cd0b40-e811-418e-b1c1-e32cc13a68e1@github.com>

On Thu, 24 Oct 2024 19:09:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>> 
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>> 
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>> 
>> 
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>> 
>> Locked ownable synchronizers:
>>     - None
>> 
>> 
>> It should be saying:
>> 
>> Locked ownable synchronizers:
>>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>> 
>> 
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>> 
>> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
>> 
>> This is a reproducer of the problem:
>> 
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>> 
>> 
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanups

Looks good. Please update the SA copyrights before integrating.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2393613327

From aivanov at openjdk.org  Thu Oct 24 20:26:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:26:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
Message-ID: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>

On Thu, 24 Oct 2024 17:58:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> It was missed when `-Djava.security.manager=allow` was removed.

It wasn't intentional then, was it?

> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?

I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.

Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.

https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49

It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815652996

From aivanov at openjdk.org  Thu Oct 24 20:30:39 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 24 Oct 2024 20:30:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
Message-ID: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>

On Thu, 24 Oct 2024 18:09:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Desktop.java line 713:
>> 
>>> 711:      * {@code Info.plist}.
>>> 712:      *
>>> 713:      * @param printFileHandler handler
>> 
>> Suggestion:
>> 
>>      * @param printFileHandler handler
>>      *
>> 
>> ~~Can we add a blank line here? It's present in the methods above.~~
>> 
>> Although there are other places below where it's missing; _so not worth worrying_.
>
> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.

@honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.

If it's worth taking care of, we may submit another bug to address it later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815657461

From mullan at openjdk.org  Thu Oct 24 21:00:39 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 24 Oct 2024 21:00:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
 <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
Message-ID: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>

On Thu, 24 Oct 2024 20:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @seanjmullan Can you please advice on some of the following src file javadoc related review comments. Do they need to be handled in this PR? Some of them seem out-of-scope for jep486 PR.
>
> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.
> 
> If it's worth taking care of, we may submit another bug to address it later.

This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815686941

From rkennke at openjdk.org  Thu Oct 24 21:04:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 21:04:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v53]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Enable riscv in CompressedClassPointersEncodingScheme test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/c2f6d202..434c6817

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=51-52

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Oct 24 21:04:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 24 Oct 2024 21:04:51 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v51]
In-Reply-To: <6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <V0bl0ewTz3kmPqZhynFqVFjlKjtpzxLCax-Yua5wCTQ=.326f5fee-58bd-4085-a4e8-3848f23f9cbe@github.com>
 <6cP6tvH2d8TU7TEuAxZoAtXFHg2jhtLEpOogKSCIeDE=.d2c3cce9-bb23-48c8-8829-8edd14249842@github.com>
Message-ID: <YfqWH6yBeIGE9yXnmP1j70P48QMaVrUa-RJGwVTw1yU=.70c9bb75-d223-4795-9438-1e76c315ffe3@github.com>

On Thu, 24 Oct 2024 18:58:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test
>
> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 107:
> 
>> 105:         // the encoding range. We expect the encoding Base to start at the class space start - but to enforce that,
>> 106:         // we choose a high address.
>> 107:         if (Platform.isAArch64() || Platform.isX64()) {
> 
> @rkennke please also enable riscv for this test `CompressedClassPointersEncodingScheme.java`, it passed in my environment. Thanks!

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1815690759

From pchilanomate at openjdk.org  Thu Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <DEan9Tspd0UIgQiYMSha9fLGDa0BLD6wEa2w1en9bmg=.dd579010-ff63-4927-ab2c-5972e178b785@github.com>

On Thu, 24 Oct 2024 02:41:43 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/Thread.java line 654:
> 
>> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 
> Suggestion:
> 
>      * counter is off-heap and shared with the VM to allow it to assign thread

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906

From pchilanomate at openjdk.org  Thu Oct 24 21:08:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:08:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Rename set/has_owner_anonymous to set/has_anonymous_owner
 - Fix comments in javaThread.hpp and Thread.java
 - Rename nonce/nounce to seqNo in VirtualThread class
 - Remove ObjectMonitor::set_owner_from_BasicLock()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/03ba6dfb..c7a82c45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=07-08

  Stats: 66 lines in 10 files changed: 2 ins; 37 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From honkar at openjdk.org  Thu Oct 24 21:10:36 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 21:10:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
Message-ID: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>

On Thu, 24 Oct 2024 20:23:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> It was missed when -Djava.security.manager=allow was removed. 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in `/othervm` mode when it is not needed?
>
>> It was missed when `-Djava.security.manager=allow` was removed.
> 
> It wasn't intentional then, was it?
> 
>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
> 
> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
> 
> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
> 
> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
> 
> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.

@aivanov-jdk 
Right, it wasn't intentionally but missed when removing `-Djava.security.manager=allow`.

> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.

Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good to remove, I can probably do a replace-all on beans/XMLEncoder/ folder.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815694898

From pchilanomate at openjdk.org  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <Zdgu1MQK0JK9kEfpPPET-aG_zv8zAp3-Tg2uRgJ_Tf4=.757f4ade-f6a6-4ffe-b363-b04613d0b720@github.com>
 <PtyZkDyAH_7R543OqpdWqCzqD2y2jyZ2vGm-UTZxPZY=.33d88f5e-32b5-40c7-bab3-eeff49ed7f25@github.com>
Message-ID: <pTM3f2szGU_CSb0ASohOPwIKQQjLpKyquSrfFjCmpew=.3e7e9e9f-ae59-4a6c-b944-19324445d944@github.com>

On Thu, 24 Oct 2024 06:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.
>
> Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:
> 
> Before: owner = BasicLock* belonging to current
> After: owner = JavaThread* of current
> 
> with the new version we have:
> 
> Before: owner = ANONYMOUS_OWNER
> After: owner = tid of current
> 
> so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

I see your point. I removed this method and had the only caller just call set_owner_from_anonymous() and set_stack_locker(nullptr). There was one other caller in ObjectMonitor::complete_exit() but it was actually not needed so I removed it. ObjectMonitor::complete_exit() is only called today on JavaThread exit to possibly unlock monitors acquired through JNI that where not unlocked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784

From pchilanomate at openjdk.org  Thu Oct 24 21:17:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <lXjBmrBbDwUhWRYdqE-ZikoacYNy6aldPQXii7sa8hs=.98502724-3fe8-48fc-8faf-0e9984924ede@github.com>
Message-ID: <K_hfNhC2_eMjYjNAZQbT9dL7pGz7cdcfKas7rSbigbA=.f6ef4f24-3473-47c9-833f-c9158457fdcd@github.com>

On Thu, 24 Oct 2024 05:10:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value. Also,
>> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread
> 
> s/temporary change/temporarily change/

Fixed.

> src/java.base/share/classes/java/lang/Object.java line 383:
> 
>> 381:             try {
>> 382:                 wait0(timeoutMillis);
>> 383:             } catch (InterruptedException e) {
> 
> I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

We jump to `StubRoutines::cont_preempt_stub()`. We need to remove all the frames that were just copied to the heap from the physical stack, and then return to the calling method which will be `Continuation.run`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043

From pchilanomate at openjdk.org  Thu Oct 24 21:17:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v8]
In-Reply-To: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.92f04ba4-1841-4c6f-8896-950202f548ff@github.com>
Message-ID: <gLdoEBbkdZ34VkSGPRJ9GVsSE3guDPf_s8Rk0eiv6N8=.6b76a553-a3e5-4330-8f24-8ee5647dc9da@github.com>

On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix comment in objectMonitor.hpp and javaThread.hpp
>>  - Skip printing tid when not available
>
> src/hotspot/share/runtime/objectMonitor.hpp line 325:
> 
>> 323:   }
>> 324: 
>> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

I renamed both `set/has_owner_anonymous` to `set/has_anonymous_owner`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701746

From pchilanomate at openjdk.org  Thu Oct 24 21:17:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <i2BRCkPmAaFopJCUHlnUjKlaahQbwnifHjvu6GiMh7U=.88f208d9-eb95-464c-860e-0f7eab6d3e7d@github.com>

On Thu, 24 Oct 2024 02:57:18 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 631:
> 
>> 629:         // Object.wait
>> 630:         if (s == WAITING || s == TIMED_WAITING) {
>> 631:             byte nonce;
> 
> Suggestion:
> 
>             byte seqNo;

Changed to seqNo.

> src/java.base/share/classes/java/lang/VirtualThread.java line 948:
> 
>> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
>> 947:      */
>> 948:     private void waitTimeoutExpired(byte nounce) {
> 
> I assume you meant `nonce` here, but please change to `seqNo`.

Changed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 1397:
> 
>> 1395: 
>> 1396:     /**
>> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.
> 
> Suggestion:
> 
>      * Returns a lock object for coordinating timed-wait setup and timeout handling.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815699934
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312

From pchilanomate at openjdk.org  Thu Oct 24 21:17:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 24 Oct 2024 21:17:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
Message-ID: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>

On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>>
>> Yes.
>
> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697084

From kevinw at openjdk.org  Thu Oct 24 21:32:05 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 24 Oct 2024 21:32:05 GMT
Subject: RFR: 8339289: Enhance Attach API to support arbitrary length
 arguments - Windows [v5]
In-Reply-To: <iWv7pZoVkaW9evjBzWCjW_xgBi11cpSCP-WMChm-A6A=.2e182ba2-71db-4149-897b-196e84d99f50@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <iWv7pZoVkaW9evjBzWCjW_xgBi11cpSCP-WMChm-A6A=.2e182ba2-71db-4149-897b-196e84d99f50@github.com>
Message-ID: <E7G4PfadgVeAsDHjapMIujSPOTw7n9YdXwJutFkWxss=.7a8d43c3-ea54-4586-8056-969d394e80fe@github.com>

On Thu, 24 Oct 2024 18:58:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - renamed getVersion command
>  - typos

Marked as reviewed by kevinw (Reviewer).

Thanks for updating, looks good.  I think it's clearer now that this is not just a Windows-specific fix, but will be an enhancement for all platforms in the long term.  Likely argument length is more of a limitation than number of arguments.

Looking back at JDK-8215622: Add dump to file support for jmap ?histo
..and that was extending the "inspectheap" attach command, but it should have been using a DiagnosticCommand invoked by jcmd.  We may not say it clearly, but the attach api commands are a few basic fundamentals, and most of what we want to implement should be implemented in a DiagnosticCommand.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20782#pullrequestreview-2393738967
PR Comment: https://git.openjdk.org/jdk/pull/20782#issuecomment-2436370162

From ihse at openjdk.org  Thu Oct 24 22:15:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 24 Oct 2024 22:15:08 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
Message-ID: <blGOVgYqxowsDcbJcsqn-2e0zsKV2UzmAHvmWYw-ZGc=.d8eb7778-994a-4ed1-949e-3b995b2406a1@github.com>

On Thu, 24 Oct 2024 14:22:28 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8342682

All the original labels are still there. A better approach had probably been to close the PR and open a new. You either need to do that now, or delete all the irrelevant labels. (I can't be bothered to figure out; at least build is wrong.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2436431780

From dholmes at openjdk.org  Thu Oct 24 22:16:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <hAeedCwwRYw4p4ioxVrHHYKm6BK-y_fXKXd7XBf0DZw=.dc9a177b-7346-4e6f-a5fa-0e23e5d45aa3@github.com>
 <DJ2Vmf5dWy7JdxhsMkh9knCSdXWi-udkCw5NDTVExwE=.4e687934-b821-42a5-8c11-4dc6a123d029@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.073a2157-37e9-40fb-aee3-c15858649c34@github.com>
Message-ID: <uhNEFqOmOPAUXR5vCaSiMeOvh23OjcpBiUgxjZ5PByU=.6bcb0a5f-e0e1-4ed3-b5d8-b470e2859375@github.com>

On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
>> 
>> RUNNING -> BLOCKING -> BLOCKED
>> BLOCKED -> UNBLOCKING -> RUNNABLE
>> 
>> I'm just trying to get a better sense of what we can infer if we see these "transition" states.
>
> We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305

From dholmes at openjdk.org  Thu Oct 24 22:16:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 24 Oct 2024 22:16:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
Message-ID: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>

On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.
>
> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815762233

From honkar at openjdk.org  Thu Oct 24 22:27:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:27:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <gIwlmNzUQN7CM7jX7Tq5CQkS1Ay_fWsPrZABjIRdHeo=.ba7f210c-8a6a-4e47-9c00-830476aa158b@github.com>

On Thu, 24 Oct 2024 16:35:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/awt/Focus/CloseDialogActivateOwnerTest/CloseDialogActivateOwnerTest.java line 28:
> 
>> 26:   @key headful
>> 27:   @bug       6785058
>> 28:   @summary   Tests that an owner is activated on closing its owned dialog with the warning icon.
> 
> Does this test remain relevant without the security manager? Without the security manager, there will be no dialogs with the warning icon.

Looks like the test was created for SM specific issue - [JDK-6785058](https://bugs.openjdk.org/browse/JDK-6785058). I have deleted the test here https://github.com/openjdk/jdk-sandbox/commit/de0a0f67ef207e1d217c42c312a4378f9f7fa833

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815770344

From honkar at openjdk.org  Thu Oct 24 22:31:41 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 24 Oct 2024 22:31:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <C6AQiFYXzD9ov3ZvyWThfp_FUec5f-cLLOyPkqLBeeE=.f3c888ca-d459-44ad-9c18-2329869ffa18@github.com>

On Thu, 24 Oct 2024 16:11:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 6343:
> 
>> 6341:      *                           <code>GraphicsEnvironment.isHeadless</code>
>> 6342:      *                           returns <code>true</code>
>> 6343:      *          method disallows this thread from creating a print job request
> 
> Suggestion:
> 
> 
> One more line to remove here.

Relevant (w.r.t jep486) javadocs changes have been updated here: https://github.com/openjdk/jdk-sandbox/commit/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815773023

From amenkov at openjdk.org  Thu Oct 24 23:05:07 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 23:05:07 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
Message-ID: <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>

On Thu, 24 Oct 2024 14:52:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: removed asserts from continuationFreezeThaw.cpp again

src/hotspot/share/prims/jvmtiEnvBase.cpp line 667:

> 665: 
> 666: javaVFrame*
> 667: JvmtiEnvBase::check_and_skip_hidden_frames(bool is_in_VTMS_transition, javaVFrame* jvf) {

reworked function looks much better! Now it's clear what the function does and I have a question what it should do.
The function checks `@JvmtiMountTransition` annotation first even if the thread is in transition.
If `@JvmtiMountTransition` is present, the code doesn't care about `@ChangesCurrentThread` (and doesn't case about `@JvmtiMountTransition` if in_transition + `@ChangesCurrentThread`).
But we have 2 methods in VirtualThread class (`switchToCarrierThread()` and `switchToVirtualThread()`) with both annotations.
So if the function is called when `switchToCarrierThread` is on top, the function skips this frame, but if the thread calls some other function without `@JvmtiMountTransition` annotation from `switchToCarrierThread`, the function returns `switchToCarrierThread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1815790409

From amenkov at openjdk.org  Thu Oct 24 23:12:11 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 24 Oct 2024 23:12:11 GMT
Subject: RFR: 8339289: Enhance Attach API to support arbitrary length
 arguments - Windows [v5]
In-Reply-To: <iWv7pZoVkaW9evjBzWCjW_xgBi11cpSCP-WMChm-A6A=.2e182ba2-71db-4149-897b-196e84d99f50@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
 <iWv7pZoVkaW9evjBzWCjW_xgBi11cpSCP-WMChm-A6A=.2e182ba2-71db-4149-897b-196e84d99f50@github.com>
Message-ID: <MwpINeEsDrdFzE6qQ2hsod4YSkBcM9KwJyYZcltOKww=.b65b16d8-c146-4bcb-8304-fab6396d1ca4@github.com>

On Thu, 24 Oct 2024 18:58:26 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
>> More detailed explanations on the 1st comment.
>> 
>> 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) on Windows with jdk21u and jdk8u.
>
> Alex Menkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - renamed getVersion command
>  - typos

Thank you for review Serguei and Kevin
I'm going to rebase the change and run sanity tests before integration

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20782#issuecomment-2436493835

From dholmes at openjdk.org  Fri Oct 25 00:14:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 00:14:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <nl9Di_JEDI2KSzXhFfRJxrsz7XXyYOnTW_j_te2ToeU=.8290bee1-1f3f-44a4-b149-ec1cac7eaf28@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702

From psadhukhan at openjdk.org  Fri Oct 25 04:57:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 04:57:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <4p_vfip2UXM3K4lU7A7163Iz62qQhHKl01DUIIuqi1k=.9971fe7c-d560-4c83-9bb2-d315de51454c@github.com>
 <Zh8F-nC25fWkBnFHEtI-tdFu4mTyk6RBWeCbdnackaA=.95a3e458-b28a-4995-b3c1-42aa1e9e678d@github.com>
 <52659hNDEGAt6JC9HC6IUw4Qy1QFRkc23w7IQpKYCcs=.2fc5b1a9-e9b9-4f36-aacc-b48b8e360798@github.com>
 <6ApqXmPZcKXKJ8E4Wd2wvLT-2CNcpN_XglBX983HrQA=.11574ea5-7949-4355-8f9f-4cd5f2101ed4@github.com>
 <8qd_9S3KCF53zPpIFtrjcD1BFljqTa4_Qu1qrhtJeFg=.453b851a-4e89-454f-98a1-4c57901accdc@github.com>
Message-ID: <3cbgckSg8DmaAkUalu54f2S9UMmrVrgo7SNQ1Eb1PvM=.a2830527-7ffc-48d2-8191-85c861f30b6f@github.com>

On Thu, 24 Oct 2024 17:27:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I think we have finally decided that jtreg tag will come after copyright and before imports...Applicable for all modified javax_swing tests in this PR...
> 
> Did we agree on that?

Atleast client-dev team did..
See this initial note https://github.com/openjdk/jdk/pull/18414/files#r1534605049
And also in our internal meeting, Phil mentioned if IDE is having issue with this tag order (like collapsing) it's IDE's problem and they should be rectified and we should not change our product code for that..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1815994453

From dholmes at openjdk.org  Fri Oct 25 06:09:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 25 Oct 2024 06:09:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

Next batch of comments ...

src/hotspot/share/classfile/javaClasses.cpp line 2082:

> 2080: }
> 2081: 
> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {

Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?

I'm struggling to understand how a thread can already be on this list?

src/hotspot/share/classfile/javaClasses.cpp line 2086:

> 2084:   jboolean vthread_on_list = Atomic::load(addr);
> 2085:   if (!vthread_on_list) {
> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);

It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

src/hotspot/share/code/nmethod.cpp line 711:

> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Suggestion:

  if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
      JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

src/hotspot/share/runtime/objectMonitor.cpp line 132:

> 130: 
> 131: // -----------------------------------------------------------------------------
> 132: // Theory of operations -- Monitors lists, thread residency, etc:

This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage

src/hotspot/share/runtime/objectMonitor.cpp line 1140:

> 1138: }
> 1139: 
> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {

Explanatory comment would be good - thanks.

src/hotspot/share/runtime/objectMonitor.cpp line 1532:

> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
> 1531:     // Virtual thread case.
> 1532:     Trigger->unpark();

So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

src/hotspot/share/runtime/objectMonitor.cpp line 1673:

> 1671: 
> 1672:   ContinuationEntry* ce = current->last_continuation();
> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {

So IIUC this use of `interruptible` would be explained as follows:

// Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
// All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
// this is a regular Object.wait call.

src/hotspot/share/runtime/objectMonitor.cpp line 1698:

> 1696:     // on _WaitSetLock so it's not profitable to reduce the length of the
> 1697:     // critical section.
> 1698: 

Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

src/hotspot/share/runtime/objectMonitor.cpp line 2028:

> 2026:   // First time we run after being preempted on Object.wait().
> 2027:   // Check if we were interrupted or the wait timed-out, and in
> 2028:   // that case remove ourselves from the _WaitSet queue.

I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

src/hotspot/share/runtime/objectMonitor.cpp line 2054:

> 2052:   // Mark that we are at reenter so that we don't call this method again.
> 2053:   node->_at_reenter = true;
> 2054:   assert(!has_owner(current), "invariant");

The position of this assert seems odd as it seems to be something that should hold at entry to this method.

src/hotspot/share/runtime/objectMonitor.hpp line 174:

> 172: 
> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor

Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

src/hotspot/share/runtime/objectMonitor.hpp line 207:

> 205: 
> 206:   static void Initialize();
> 207:   static void Initialize2();

Please add comment why this needs to be deferred - and till after what?

src/hotspot/share/runtime/objectMonitor.hpp line 312:

> 310:   void      set_successor(JavaThread* thread);
> 311:   void      set_successor(oop vthread);
> 312:   void      clear_successor();

Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

src/hotspot/share/runtime/objectMonitor.hpp line 349:

> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }

This no longer looks correct if the waiter is a vthread. ??

src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:

> 108: }
> 109: 
> 110: // Returns null if DEFLATER_MARKER is observed.

Comment needs updating

src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:

> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
> 129: // This accessor is called when we really need to know if the owner
> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.

Comment needs updating

src/hotspot/share/runtime/synchronizer.cpp line 670:

> 668:   // Top native frames in the stack will not be seen if we attempt
> 669:   // preemption, since we start walking from the last Java anchor.
> 670:   NoPreemptMark npm(current);

Don't we still pin for JNI monitor usage?

src/hotspot/share/runtime/synchronizer.cpp line 1440:

> 1438: }
> 1439: 
> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {

`inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

src/hotspot/share/runtime/synchronizer.hpp line 172:

> 170: 
> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.

Comment needs updating

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815838204
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815839094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815985700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815998417
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816002660
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816009160
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816014286
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816017269
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816018848
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815956322
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815960013
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815967260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815969101
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816043275
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816047142
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816041444

From psadhukhan at openjdk.org  Fri Oct 25 06:43:42 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 06:43:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <8Oq38NBheXvpvw7sKy_5vSHd7o5r2rJmM8lQToaXmDc=.d8488397-1c79-446b-95c9-9b7a43d4b308@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed jdk javax/print and javax/swing..Looks good..

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437002459

From stefank at openjdk.org  Fri Oct 25 06:49:48 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 06:49:48 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v5]
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21662/files
  - new: https://git.openjdk.org/jdk/pull/21662/files/adc7d755..458165b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21662&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21662.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21662/head:pull/21662

PR: https://git.openjdk.org/jdk/pull/21662

From cjplummer at openjdk.org  Fri Oct 25 06:53:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 25 Oct 2024 06:53:05 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v5]
In-Reply-To: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
Message-ID: <cwgIJhoDs0dN6ttiZWOTS_YrI09Ddh1w3CQbP4PgGUw=.f15c1458-bb9d-4f0d-b28f-bd803a7ee994@github.com>

On Fri, 25 Oct 2024 06:49:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>> 
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>> 
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>> 
>> 
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>> 
>> Locked ownable synchronizers:
>>     - None
>> 
>> 
>> It should be saying:
>> 
>> Locked ownable synchronizers:
>>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>> 
>> 
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>> 
>> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
>> 
>> This is a reproducer of the problem:
>> 
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>> 
>> 
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21662#pullrequestreview-2394351437

From hannesw at openjdk.org  Fri Oct 25 07:11:18 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:18 GMT
Subject: RFR: 8342827: Fix order of @param tags in other modules [v2]
In-Reply-To: <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
 <rz7OJtPRWgU-N7ZFgl2YBGFZphePRnLia4Mo4mjuhEE=.b0b051a0-baf8-4e28-a38a-10d128f2ad43@github.com>
Message-ID: <PgAAUiIwM4y3ghPK2qfvZ8PECbU_Py3VGRyOLX4YUsM=.ede5c00f-1c52-44fe-9de4-cc1650ebb506@github.com>

On Thu, 24 Oct 2024 12:17:41 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
>> 
>> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
>> 
>> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.
>
> Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright header

Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21637#issuecomment-2437054155

From hannesw at openjdk.org  Fri Oct 25 07:11:19 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 25 Oct 2024 07:11:19 GMT
Subject: Integrated: 8342827: Fix order of @param tags in other modules
In-Reply-To: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
References: <xi1PPxNyNqm9VqqWlMXk6lW4utbtU--KDasWw6T8RYg=.3d58325c-28c9-46b8-a606-402555db8c6d@github.com>
Message-ID: <r2DQm4YM057gNfMLILLJZJswLeOxQagxBqyFAGNMU7g=.de394ac2-5105-4aea-b153-59f519148dd3@github.com>

On Tue, 22 Oct 2024 13:36:43 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Please review a doc-only change to fix the order of javadoc @param tags in in various OpenJDK modules. This is the third and last PR to fix the order of @param tags in OpenJDK libraries.
> 
> We are working on a javadoc feature to add an opt-in doclint warning for @param tags that don't match the order of parameters in the documented element. The warning will be enabled in OpenJDK builds and covers all uses of the @param tag, i.e. parameters of executable elements, type parameters, and record components.
> 
> I compared the generated API docs built with this branch with API docs built from master branch to make sure they are identical.

This pull request has now been integrated.

Changeset: fd5ff054
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd5ff0547ced6733ae05f1428664062615408dc9
Stats:     144 lines in 28 files changed: 58 ins; 58 del; 28 mod

8342827: Fix order of @param tags in other modules

Reviewed-by: jpai, iris, joehw, darcy, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/21637

From stefank at openjdk.org  Fri Oct 25 07:29:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 07:29:10 GMT
Subject: RFR: 8342857: SA: Heap iterator makes incorrect assumptions about
 TLAB layout [v5]
In-Reply-To: <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
 <fyPryzdw8KVKr0iHnuicJGEle2CV5JunN3xfGrsYxC0=.ca24dbe2-8f47-4a2a-b108-214eaf8d379c@github.com>
Message-ID: <VCr-EeSsX3rL_TzL3_3muU7xyu-PLnIXJ0cd3dCEcO0=.d1e4cbcc-236a-4580-8851-52938aefac19@github.com>

On Fri, 25 Oct 2024 06:49:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
>> 
>> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
>> 
>> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
>> 
>> 
>> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
>> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
>> 
>> Locked ownable synchronizers:
>>     - None
>> 
>> 
>> It should be saying:
>> 
>> Locked ownable synchronizers:
>>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
>> 
>> 
>> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
>> 
>> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
>> 
>> This is a reproducer of the problem:
>> 
>> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
>> 
>> 
>> I've test...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21662#issuecomment-2437083507

From stefank at openjdk.org  Fri Oct 25 07:29:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 07:29:10 GMT
Subject: Integrated: 8342857: SA: Heap iterator makes incorrect assumptions
 about TLAB layout
In-Reply-To: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
References: <lIV_Ob5b_ATRTNLNSWTTZQL1VQ35aW8A1QIOSR6Lslo=.4259ebec-6dec-45a4-a818-acabe530e206@github.com>
Message-ID: <_Yq5NToiRS624xMdkcjzZQAwK_CHjTCS0LCWlBBH8Ec=.195d3a65-273e-4e92-8b58-0fd5c6521f7d@github.com>

On Wed, 23 Oct 2024 11:39:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When testing Lilliput we found a failure in `serviceability/sa/ClhsdbJstackWithConcurrentLock.java` test when running with C1-only.
> 
> The test uses the SA's thread printing feature to print the threads *and* the "concurrent locks" / AbstractOwnableSynchronizers. It then verifies that the expected lock is listed in the section for "Locked ownable synchronizers".
> 
> When we turned on Lilliput's -XX:+UseCompactObjectHeaders this stopped working, and we got nothing reported in that section:
> 
> 
> "Thread-0" #31 prio=5 tid=0x00007a708c259ad0 nid=1480533 waiting on condition [0x00007a706fefe000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
>  - java.lang.Thread.sleepNanos0(long) @bci=0 (Interpreted frame)
>  - java.lang.Thread.sleepNanos(long) @bci=33, line=497 (Interpreted frame)
>  - java.lang.Thread.sleep(long) @bci=25, line=528 (Interpreted frame)
>  - LingeredAppWithConcurrentLock.lockMethod(java.util.concurrent.locks.Lock) @bci=13, line=38 (Interpreted frame)
> 	- locked <0x00000000ffd32d88> (a java.util.concurrent.locks.ReentrantLock)
>  - LingeredAppWithConcurrentLock.lambda$main$0() @bci=3, line=46 (Interpreted frame)
>  - LingeredAppWithConcurrentLock$$Lambda+0x00007a7023001000.run() @bci=0 (Interpreted frame)
>  - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1589 (Interpreted frame)
>  - java.lang.Thread.run() @bci=19, line=1576 (Interpreted frame)
> 
> Locked ownable synchronizers:
>     - None
> 
> 
> It should be saying:
> 
> Locked ownable synchronizers:
>     - <0x00000000ffd32d88>, (a java/util/concurrent/locks/ReentrantLock$NonfairSync)
> 
> 
> The problem lies within the code that searches for objects in the heap. It collects a bunch of regions and searches them for objects. However, the code that describes the TLAB regions are stale and doesn't match the C++ implementation in the JVM. When Lilliput shrinks the headers the SA code is broken enough to cause the TLAB regions to be reported as overlapping. This has ripple effects that the object iterators stop working.
> 
> I can get this test to pass, with and without compact object headers, by fixing the code in  `ThreadLocalAllocBuffer::hard_end()`.
> 
> This is a reproducer of the problem:
> 
> make -C ../build/fastdebug test TEST=serviceability/sa/ClhsdbJstackWithConcurrentLock.java JTREG="JAVA_OPTIONS=-XX:TieredStopAtLevel=2 -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"
> 
> 
> I've tested this by running all 'serviceability' tests in our tier1-9 testing.

This pull request has now been integrated.

Changeset: 3c5db12b
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c5db12bbe4d1155ab874c2862005621c6b8541d
Stats:     46 lines in 3 files changed: 23 ins; 13 del; 10 mod

8342857: SA: Heap iterator makes incorrect assumptions about TLAB layout

Reviewed-by: cjplummer, rkennke, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/21662

From jwaters at openjdk.org  Fri Oct 25 07:57:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 25 Oct 2024 07:57:07 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
Message-ID: <FSfWDjm6mlvlP8LWUwQ4AY4Wo69CDLEopKIR01ZP60M=.363ff556-2cb8-422a-8f93-6211dcca19ff@github.com>

On Thu, 24 Oct 2024 14:22:28 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8342682

I don't know what label jpackage falls under

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2437133404

From aboldtch at openjdk.org  Fri Oct 25 08:25:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 25 Oct 2024 08:25:21 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Remove GCName::Z
 - Merge tag 'jdk-24+21' into JDK-8341692
   
   Added tag jdk-24+21 for changeset 8bcd4920
 - Merge tag 'jdk-24+20' into JDK-8341692
   
   Added tag jdk-24+20 for changeset 7a64fbbb
 - Merge tag 'jdk-24+19' into JDK-8341692
   
   Added tag jdk-24+19 for changeset e7c5bf45
 - LargeWindowPaintTest.java fix id typo
 - Fix problem-listed @requires typo
 - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
 - Reorder z_globals options: product > diagnostic product > develop
 - Consistent albite special code style
 - Consistent order between ZArguments and GCArguments
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

-------------

Changes: https://git.openjdk.org/jdk/pull/21401/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21401&range=04
  Stats: 39435 lines in 407 files changed: 155 ins; 39010 del; 270 mod
  Patch: https://git.openjdk.org/jdk/pull/21401.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21401/head:pull/21401

PR: https://git.openjdk.org/jdk/pull/21401

From stefank at openjdk.org  Fri Oct 25 09:31:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Oct 2024 09:31:09 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <oq59eejHdICbFJMnj-3mrGlgFeH9P_vahgWD8BPEHgs=.3084edd8-9526-4d5b-86ec-883ef7274746@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2394745512

From eosterlund at openjdk.org  Fri Oct 25 09:37:10 2024
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 25 Oct 2024 09:37:10 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <30WXGwanfqdFmkKex3iqECu6rMjALS_GisqtOgSV2ek=.5c42b29d-1d38-41fe-8825-da3ad639b017@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Marked as reviewed by eosterlund (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2394758948

From alanb at openjdk.org  Fri Oct 25 10:24:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 25 Oct 2024 10:24:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <d5xJopNoCRLi6rkODhtvzetpYaCDeRSf84aB85h7BMc=.1f4ca506-46d7-4fac-a616-2b487017951f@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.7c004164-fb81-44a8-a322-4d0e118ba9e1@github.com>
 <5hc5EDb2Ex9xAGP2okFeNkGQbW_qjU1UKEg-zbXAtd0=.30f20bbf-f4c5-417b-888c-e15492a9a6d4@github.com>
 <z9TD38vxoEHmzKX_hgvDTvNGRcvWJhyMVPv2NOU0hoo=.0bc8d552-d7a9-4e35-989a-6848691cb27b@github.com>
 <Y8fPSNi8Pwz-GON9oV9JG7rTqMFGwk7wW2f-WH4P8N8=.c00a846e-c6e6-4087-9acb-39b9faeb5695@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.a189652a-cfa8-499c-99c8-a2e6f126a2c3@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.32839f10-ce5d-4844-9f5b-5f34d23bedee@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.2a90d035-6e8e-4cac-ac1d-f2fedb693cfd@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.1eac6280-7fbf-43c4-84b4-8f234efd74a1@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzu
 Zr6vy5zA=.3d439cbf-4ecd-4eac-b1b4-203cb94ce05e@github.com>
 <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.c23fa0f0-4420-4b43-a737-695d00c2d83a@github.com>
Message-ID: <bIj9x7QeQeCoCgHy7PkpwOy0SLdF2lRnZ8oKN7yjILk=.4f23be55-161c-46f9-b3b7-86ae1426fbb6@github.com>

On Thu, 24 Oct 2024 22:13:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.
>
> Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

We've had these temporary transitions from day 1. The changes in this PR remove one usage, they don't add any new usages. The intention is to make this nuisance go away. The last usage requires changes to the timer support, working on it. For now, it's easiest to think of it as a "java on java" issue where critical code is in Java rather than the VM. The timer issue arises when a virtual thread does a timed park needs to schedule and cancel a timer. This currently requires executing Java code that may contend on a timer or trigger a timer thread to start. This has implications for thread state, the park blocker, and the parking permit. Adding support for nested parking gets very messy, adds overhead, and is confusing for serviceability observers.  The exiting behavior is to just temporarily switch the thread identity (as in Thread::currentThread) so it executes in the context of the carrier rather than the virtual thread. As I said, we are working to make this go away, it would have 
 been nice to have removed in advance of the changes here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590

From psadhukhan at openjdk.org  Fri Oct 25 11:19:41 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <N9SCzjHG3Q-GHIk6nNj7s8_vQBkx_dirVhnTjhWpWw0=.d298d7d7-4fab-46e7-9f07-f4f39f308478@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2394343323

From dfuchs at openjdk.org  Fri Oct 25 11:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 25 Oct 2024 11:19:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <XK2j-0yrasFNv7xEkGgkrwWX09OJD29pcQPMmVd88kU=.13059532-b236-45bf-b788-626491003998@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

For the record I had a look at the changes in JMX and JNDI tests and these look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2437522137

From aivanov at openjdk.org  Fri Oct 25 11:38:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 11:38:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <t8G-Z42HQYnLMTgV05z3sbnhDoljn9_AJSb4ch4FNy4=.52604907-0af6-4dc9-ad6a-18ffa6c8b20e@github.com>
 <JTmmNeMyrU1R-irFLUqvukGh-8PbIvZcfjWqbMXYLis=.8b8e4055-52e3-454d-ad49-874b7f458ab5@github.com>
 <VWJtNGgHc2u4OEtGD9dfQNRQqWRnj8hJqN5HInMrZRw=.9e1ebc9d-5eff-43c7-856d-bcdabfb00270@github.com>
Message-ID: <xmvA-xWfN2PbFLJsskbi8HNSDlJ6ANEKeWuzLgqlzrk=.b2eb7e3f-4f25-4c3e-b5c0-e29705ab9ce4@github.com>

On Thu, 24 Oct 2024 21:06:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> It was missed when `-Djava.security.manager=allow` was removed.
>> 
>> It wasn't intentional then, was it?
>> 
>>> Out of curiosity: does it have any impact on the performance of CI testing if tests are run in /othervm mode when it is not needed?
>> 
>> I guess it does, `othervm` tests launch a new VM for each test as opposed to re-using an already running VM.
>> 
>> Anyway, removing `/othervm` isn't strictly required because `java/beans` are run in `othervm` mode.
>> 
>> https://github.com/openjdk/jdk/blob/d1540e2a49c7a41eb771fc9896c367187d070dec/test/jdk/TEST.ROOT#L48-L49
>> 
>> It caught my attention because `/othervm` is removed from tests in `beans/XMLEncoder/*/`, that is in subfolders, whereas in the `beans/XMLEncoder/` folder these are left.
>
> @aivanov-jdk 
> Right, it wasn't intentional but missed when removing `-Djava.security.manager=allow`.
> 
>> Anyway, removing /othervm isn't strictly required because java/beans are run in othervm mode.
> 
> Thank you for clarifying. Since `/othervm` doesn't impact the beans tests I'll keep it as-is. Let me know if you still think it is good idea to remove it, I could do a find and replace-all on beans/XMLEncoder/ test folder.

@honkar-jdk I've submitted [JDK-8343062](https://bugs.openjdk.org/browse/JDK-8343062) for additional cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816521679

From coleenp at openjdk.org  Fri Oct 25 12:03:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 12:03:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>

On Fri, 25 Oct 2024 03:51:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/share/runtime/objectMonitor.hpp line 174:
> 
>> 172: 
>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
> 
> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.


$ grep -r JFR_THREAD_ID
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

> src/hotspot/share/runtime/synchronizer.cpp line 1440:
> 
>> 1438: }
>> 1439: 
>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
> 
> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

If it's always the current thread, then it should be called 'current' imo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794

From mdonovan at openjdk.org  Fri Oct 25 12:19:04 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 25 Oct 2024 12:19:04 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property
In-Reply-To: <tsQFFsOeIO3fQUtFhh7SY32K7733l5T7TQ55fHtYnYg=.29a33f82-3210-47a3-b092-9bfc28392ba9@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <tsQFFsOeIO3fQUtFhh7SY32K7733l5T7TQ55fHtYnYg=.29a33f82-3210-47a3-b092-9bfc28392ba9@github.com>
Message-ID: <g35bPZFOPaGYKa7aQdLJCLmlN_Mi2bTm3OcfMdFU00c=.2ad86eb5-50fb-4792-ac74-9ddf931ffad6@github.com>

On Mon, 21 Oct 2024 12:42:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> You are changing more than SunJCE providers, so the title of this bug should not be specific to SunJCE. Suggest: "Replace hardcoded security providers with new test.provider.name system property".
> 
> Are there any cases where a test has more than one hardcoded provider?

I changed the name of the bug and PR. Yes there are cases where a test has more than one hardcoded provider.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2437630431

From mullan at openjdk.org  Fri Oct 25 12:56:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 12:56:15 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property
In-Reply-To: <g35bPZFOPaGYKa7aQdLJCLmlN_Mi2bTm3OcfMdFU00c=.2ad86eb5-50fb-4792-ac74-9ddf931ffad6@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <tsQFFsOeIO3fQUtFhh7SY32K7733l5T7TQ55fHtYnYg=.29a33f82-3210-47a3-b092-9bfc28392ba9@github.com>
 <g35bPZFOPaGYKa7aQdLJCLmlN_Mi2bTm3OcfMdFU00c=.2ad86eb5-50fb-4792-ac74-9ddf931ffad6@github.com>
Message-ID: <YMFDkROKRtZSUXVnNmw5gDveX_3W46iQU0KTg3-rQOc=.a8497931-5e51-4e88-97a6-5d033328186a@github.com>

On Fri, 25 Oct 2024 12:16:55 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> I changed the name of the bug and PR. Yes there are cases where a test has more than one hardcoded provider.

How would that work then if the property only allows you to specify one provider?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2437700655

From pchilanomate at openjdk.org  Fri Oct 25 13:17:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add comments for Coleen
 - Fix JvmtiUnmountBeginMark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/c7a82c45..0308ee4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=08-09

  Stats: 22 lines in 6 files changed: 10 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Fri Oct 25 13:17:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 13:17:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
Message-ID: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>

On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add comments for Coleen
>>  - Fix JvmtiUnmountBeginMark
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Can you write a comment what this is doing briefly and why?

Added comment.

> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
> 
>> 1548: #endif /* ASSERT */
>> 1549: 
>> 1550:   push_cont_fastpath();
> 
> One of the callers of this gives a clue what it does.
> 
>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
> 
> Why do you do this here?  Oh please more comments...

_cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
> 
>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>> 2032:     __ push_cont_fastpath();
> 
> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

> src/hotspot/share/runtime/continuation.cpp line 89:
> 
>> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
>> 88:       if (_target->has_async_exception_condition()) {
>> 89:         _failed = false;
> 
> This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

Yes, good catch.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
> 
>> 1273: 
>> 1274:   if (caller.is_interpreted_frame()) {
>> 1275:     _total_align_size += frame::align_wiggle;
> 
> Please put a comment here about frame align-wiggle.

I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:
> 
>> 1276:   }
>> 1277: 
>> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);
> 
> I also forgot what patch does.  Can you add a comment here too?

I added a comment where it is defined since it is used in several places.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:
> 
>> 1550:   assert(!cont.is_empty(), "");
>> 1551:   // This is done for the sake of the enterSpecial frame
>> 1552:   StackWatermarkSet::after_unwind(thread);
> 
> Is there a new place for this StackWatermark code?

I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

> src/hotspot/share/runtime/objectMonitor.cpp line 876:
> 
>> 874:   // and in doing so avoid some transitions ...
>> 875: 
>> 876:   // For virtual threads that are pinned do a timed-park instead, to
> 
> I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 2305:
> 
>> 2303: }
>> 2304: 
>> 2305: void ObjectMonitor::Initialize2() {
> 
> Can you put a comment why there's a second initialize function?  Presumably after some state is set.

Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816658344
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660817
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661388
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661733
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662247
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065

From mullan at openjdk.org  Fri Oct 25 13:47:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 13:47:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>

On Tue, 22 Oct 2024 20:23:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
> 
>> 38:  *
>> 39:  * @apiNote
>> 40:  * This permission cannot be used for controlling access to resources anymore
> 
> Unnecessary "anymore"

Removed this word from all `Permission` subclasses; fix will be in next update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816717534

From stuefe at openjdk.org  Fri Oct 25 14:36:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Oct 2024 14:36:12 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
Message-ID: <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>

On Wed, 2 Oct 2024 13:28:13 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - 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>

Hi Robert, sorry for the late answer, and thanks for your patience!

src/hotspot/share/runtime/mutexLocker.cpp line 299:

> 297:   MUTEX_DEFN(ThreadsSMRDelete_lock           , PaddedMonitor, service-2); // Holds ConcurrentHashTableResize_lock
> 298:   MUTEX_DEFN(ThreadIdTableCreate_lock        , PaddedMutex  , safepoint);
> 299:   MUTEX_DEFN(SharedDecoder_lock              , PaddedMutex  , service-5);

Why this? Do we print stacks under NMT lock protection?

src/hotspot/share/utilities/vmError.cpp line 724:

> 722:     MemTracker::reduce_tracking_to_summary();
> 723:     // Manually unlock if already holding lock upon entering error reporting.
> 724:     NmtVirtualMemory_lock->unlock();

Thinking this through some more, I am now unsure about my old advice. I think if we force-unlock the mutex here, there should be no need for dropping the tracking mode to summary. Sorry if I gave conflicting advice before.

So I think you could remove the reduce_tracking call (and its implementation).

Dropping to summary has the disadvantage that it makes the NMT report in the hs-err file look like user ran with summary more active, which may confuse analysts. Force-unlocking is the way to go.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20852#pullrequestreview-2395460924
PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1816783901
PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1816797491

From asmehra at openjdk.org  Fri Oct 25 15:05:12 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 15:05:12 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <dQQmsawG5xpu_rrJmjGOfEs0LjV0gkYSqEBoTUXvU8M=.31d49b2e-1565-4fb0-b0b5-9ef82669ffe4@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

src/hotspot/share/cds/aotClassLinker.cpp line 117:

> 115: 
> 116: void AOTClassLinker::add_candidate(InstanceKlass* ik) {
> 117:   _candidates->put_when_absent(ik, true);

I just noticed the use of `put_when_absent` here. This means the caller should ensure that `ik` has not already been added to the `_candidates`. We do that currently (`try_add_candidate` calls `is_candidate` before calling `add_candidate`) but probably worth mentioning this contract explicitly in a comment somewhere for future readers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1816850893

From asmehra at openjdk.org  Fri Oct 25 15:11:11 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 15:11:11 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <tP5EfzpobXgMoEGxbYC-LD7J7Pk320Jm3-pOngBVv7M=.31f1a153-6e12-41b5-adca-79ee78117279@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

@iklam I remember there was [ConstantPool::iterate_archivable_resolved_references](https://github.com/iklam/jdk/blob/f0bc1ae60fea80d5914d520457986a753e75fae4/src/hotspot/share/oops/constantPool.cpp#L288) in https://github.com/openjdk/jdk/pull/21143 but I don't see it any more in this PR. Can you please comment on why was that removed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2438079354

From stuefe at openjdk.org  Fri Oct 25 15:15:07 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 25 Oct 2024 15:15:07 GMT
Subject: RFR: 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: <d3r0etEQmAznblWF456XYRySahieTf-PLhhnseP9y6o=.07d079b5-c40a-48fe-b76e-da3c7da495b5@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](https://github.com/user-attachments/files/17517412/sample.txt)

Nice work, thank you. Small nits inside. I have no time to test this extensively, but if the tests run through, it should be fine.

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 120:

> 118: 
> 119:   static const char* tagToStr(uint32_t user_tag) {
> 120:     switch (user_tag) {

You could reduce the code and remove duplications with an [x macro](https://en.wikipedia.org/wiki/X_macro) if you wanted.

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 360:

> 358:       break;
> 359:     } else if (retval < (int)sizeof(region_info)) {
> 360:       fatal("proc_pidinfo() returned %d", retval);

I would make this an assert, and return without printing anything in release.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2395601473
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1816880506
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1816894551

From michaelm at openjdk.org  Fri Oct 25 16:11:46 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 25 Oct 2024 16:11:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TJNWAEiPXYUxNLNQSveRSSTbV6KUK2aDTjUBN-V-Q9M=.97954e4d-05d7-480a-94a6-ca283458596d@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've reviewed the networking tests and they look fine. There are tests that possibly don't need the `othervm` keyword any more, and some tests that still do permission implies tests (without a security manager) but these can be updated independently in future PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438222428

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Changes requested by aivanov (Reviewer).

test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:

> 1: /*

I believe this test becomes irrelevant without `SecurityManager`.

The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:

> 1: /*

I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.

If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.

The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 44:

> 42:     private static JFrame frame;
> 43:     private static JPopupMenu popupMenu;
> 44:     private static volatile boolean isAlwaysOnTop1 = false;

Suggestion:

    private static volatile boolean isAlwaysOnTop = false;

There's only one flag now, it needs no modifier.

test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 54:

> 52: 
> 53:             SwingUtilities.invokeAndWait(bug6691503::testApplication);
> 54:             robot.delay(200);

The additional delay is redundant.

test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:

> 39:  * @bug 6694823
> 40:  * @summary Checks that popup menu cannot be partially hidden
> 41:  *          by the task bar.

I believe this test is irrelevant without the security manager.

The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.

Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:

> 1: /*

Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.

Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395179909
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816616064
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816806950
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816827134
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816826424
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816840082
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816896526

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>

On Fri, 25 Oct 2024 15:12:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
> 
>> 1: /*
> 
> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
> 
> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.

This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.

Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.

However, a more thorough analysis is required.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1816923550

From aivanov at openjdk.org  Fri Oct 25 16:55:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 16:55:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
Message-ID: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>

On Fri, 25 Oct 2024 15:29:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6622002/bug6622002.java line 1:
>> 
>>> 1: /*
>> 
>> Again, I'm unsure this test has a value after the security manager is removed. All it verifies is that whatever reflection is used in `UIDefaults.ProxyLazyValue` works.
>> 
>> Anyway, the updated test doesn't verify the issue reported in the bug, which is to prevent instantiation of values using non-public classes.
>
> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
> 
> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
> 
> However, a more thorough analysis is required.

The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817034884

From mdonovan at openjdk.org  Fri Oct 25 17:15:34 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 25 Oct 2024 17:15:34 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v4]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <jRKGV3_VgkBoy-UkFHqeoOSqu_O3oQ28ZaGVeZqb2Os=.20615bcf-40d2-4541-b5db-69b4df5f3efe@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - removed a couple instances of provider property
 - Merge branch 'master' into jce-provider-prop
 - fixed whitespace
 - Updated a few more tests.
 - 8341927: Remove hardcoded SunJCE provider

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/7dbe83e8..298670c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=02-03

  Stats: 133161 lines in 881 files changed: 108205 ins; 21652 del; 3304 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From mchung at openjdk.org  Fri Oct 25 17:29:17 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 25 Oct 2024 17:29:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
Message-ID: <FkxtznpxqChlt5BT4JAL3tkjv7vJu-QBC7sBeCg8wQc=.24c36c93-0ed3-4e9f-84c7-4c286df12603@github.com>

On Fri, 25 Oct 2024 13:17:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments for Coleen
>  - Fix JvmtiUnmountBeginMark

I looked at java.lang.ref and java.lang.invoke changes.   ReferenceQueue was reverted back to use synchronized and also adding the code disable/enable preemption looks right.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438401789

From mdonovan at openjdk.org  Fri Oct 25 17:31:06 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 25 Oct 2024 17:31:06 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property
In-Reply-To: <YMFDkROKRtZSUXVnNmw5gDveX_3W46iQU0KTg3-rQOc=.a8497931-5e51-4e88-97a6-5d033328186a@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <tsQFFsOeIO3fQUtFhh7SY32K7733l5T7TQ55fHtYnYg=.29a33f82-3210-47a3-b092-9bfc28392ba9@github.com>
 <g35bPZFOPaGYKa7aQdLJCLmlN_Mi2bTm3OcfMdFU00c=.2ad86eb5-50fb-4792-ac74-9ddf931ffad6@github.com>
 <YMFDkROKRtZSUXVnNmw5gDveX_3W46iQU0KTg3-rQOc=.a8497931-5e51-4e88-97a6-5d033328186a@github.com>
Message-ID: <cAb__2O8eGHRBbM70TdVt2nVqswiI84c_eA7dFWWqzM=.e8856e89-9652-430d-ae3c-cce6ef024593@github.com>

On Fri, 25 Oct 2024 12:53:04 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> > I changed the name of the bug and PR. Yes there are cases where a test has more than one hardcoded provider.
> 
> How would that work then if the property only allows you to specify one provider?

The tests with multiple, hardcoded providers do that because the SunJCE provider doesn't implement every engine/algorithm. I've seen this mostly with Signatures and KeyPairGenerators. A provider specified via the property would have to implement all of the operations used in the test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2438406536

From honkar at openjdk.org  Fri Oct 25 17:33:44 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 17:33:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>

On Fri, 25 Oct 2024 14:57:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
> 
>> 39:  * @bug 6694823
>> 40:  * @summary Checks that popup menu cannot be partially hidden
>> 41:  *          by the task bar.
> 
> I believe this test is irrelevant without the security manager.
> 
> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
> 
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.

This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817093001

From aivanov at openjdk.org  Fri Oct 25 17:56:43 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 17:56:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
Message-ID: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>

On Fri, 25 Oct 2024 17:30:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 41:
>> 
>>> 39:  * @bug 6694823
>>> 40:  * @summary Checks that popup menu cannot be partially hidden
>>> 41:  *          by the task bar.
>> 
>> I believe this test is irrelevant without the security manager.
>> 
>> The test above, `test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java` asserts that popup menus in applets don't have their always-on-top flag set to true, therefore such popups will be displayed below the taskbar.
>> 
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> We have a specific test which verifies [`TaskbarPositionTest.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/Popup/TaskbarPositionTest.java) that a popup menu could overlap the taskbar.
>
> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.

The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.

> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)

There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.

The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817116860

From bpb at openjdk.org  Fri Oct 25 18:03:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 25 Oct 2024 18:03:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v10]
In-Reply-To: <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <edkK_VyBDjFjFNMQwlvKNQugXasXGxKlfOjz1Da4FdE=.1e7bdd81-24c4-4cc9-b50c-526d9805aaf2@github.com>
Message-ID: <ZjehOI9RwnlCQfoK6WlUYkqoqU3nW6c8f80l0pSZ1YQ=.26e7c29b-5864-45f2-9d37-0eabdbd235b7@github.com>

On Fri, 25 Oct 2024 13:17:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments for Coleen
>  - Fix JvmtiUnmountBeginMark

The `InternalLock` and `ByteArrayOutputStream` changes look all right. I'll follow up with [JDK-8343039](https://bugs.openjdk.org/browse/JDK-8343039) once this PR for [JEP 491](https://openjdk.org/jeps/491) is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438461962

From amenkov at openjdk.org  Fri Oct 25 18:11:16 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 25 Oct 2024 18:11:16 GMT
Subject: Integrated: 8339289: Enhance Attach API to support arbitrary length
 arguments - Windows
In-Reply-To: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
References: <9PRn9DGh4QQNdVZgnWUtyoEeajE93Gu8q7G4ucIXN9A=.7c6abdd5-f690-49f1-882b-f08843245db5@github.com>
Message-ID: <4r2ES37bPsFjY8NK1vzh0RW1V4p888e0uu3Jen6oSu8=.8113a8b4-f132-45d8-979e-b039d603f210@github.com>

On Fri, 30 Aug 2024 00:07:50 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix improves Attch API protocol and implements updated protocol on windows; shared code is ready to implement updated protocol support on other platforms.
> More detailed explanations on the 1st comment.
> 
> 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) on Windows with jdk21u and jdk8u.

This pull request has now been integrated.

Changeset: 36d71735
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36d71735e3554264e8d17f7e0e72999ac639e398
Stats:     983 lines in 7 files changed: 771 ins; 139 del; 73 mod

8339289: Enhance Attach API to support arbitrary length arguments - Windows

Reviewed-by: kevinw, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/20782

From aivanov at openjdk.org  Fri Oct 25 18:12:44 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:12:44 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:

> 40:         } catch (ServiceConfigurationError sce) {
> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
> 42:             System.out.println("Test Passed");

Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438514238
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817159883

From duke at openjdk.org  Fri Oct 25 18:19:33 2024
From: duke at openjdk.org (Larry Cable)
Date: Fri, 25 Oct 2024 18:19:33 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong
 behavior when pid == ns_pid
Message-ID: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>

the implementation I originally provided does not in fact solve the issue!

the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).

"attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.

with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).

in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.

In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".

In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".

since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).

thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.

thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.

therefore an "attacher" has two choices when attempting to attach:

- use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
  - this works with both peers and descendants

- use /tmp
  - this only works if the "attacher" and "attachee" share a /tmp in common

the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.

In these circumstances, the "attacher" can only resort to /tmp which may or may not be in common with the "attachee".

the logic required for an "attacher" to determine if an "attachee" /tmp *is* in common unfortunately requires read access (from the attacher) to the"attachee's" /proc filesystem (namely to read namespace identities and to also 'stat(2)' the /proc/<pid>/root/tmp directory to obtain device and inode values for comparison in order to determine if "/tmp" is in common.

when the "attachee" has elevated privileges, this access is not available to the "attacher".

therefore in such circumstances, the "attacher" has no choice but to attempt
to use /tmp and simply timeout the handshake if in fact the "attachee" does not share a /tmp in common

In this elevated case, there is a remote possibility that another process (in the attacher's pid ns) shares the same pid as the attachee (in its descendant pid ns) in this case, if they do not share a filesystem in common the attacher may attempt
to attach to an unsuspecting process in its pid ns, this could result in that process being killed.

In order to reduce the possibility of this mis-attach resulting in process death, the attacher now tests the attachee to determine if it can participate in the attach handshake, by inspecting its signal masks and not delivering the signal to
the attachee if it is not catching the signal.

-------------

Commit messages:
 - JDK-8342449: fixed a couple of jcheck issues, modified AttachNotSupportedException to indicate that attachee is not ready to accept SIGQUIT
 - JDK-8342449: resolve remaing jcheck issues, amend AttachNotSupportedException when attachee is not ready to accept SIGQUIT
 - JDK-8342449: cleaned up tabs etc for jcheck
 - JDK-8342449: ignore blocked SIGQUIT in checkCatchesAndSendQuitTo
 - JDK-8342449: suppressed AttachNotSupportedException from checkCatchesAndSendQuitTo
 - JDK-8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid

Changes: https://git.openjdk.org/jdk/pull/21688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342449
  Stats: 158 lines in 1 file changed: 71 ins; 63 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/21688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21688/head:pull/21688

PR: https://git.openjdk.org/jdk/pull/21688

From pchilanomate at openjdk.org  Fri Oct 25 18:34:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:34:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add/fix comments for David
 - Move condition to new line in nmethod::preserve_callee_argument_oops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0308ee4c..d6313cf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=09-10

  Stats: 20 lines in 6 files changed: 14 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From honkar at openjdk.org  Fri Oct 25 18:36:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 18:36:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
Message-ID: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>

On Fri, 25 Oct 2024 17:52:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This particular test was failing on windows & linux after SM removal. There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>
> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> 
> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
> 
>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
> 
> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
> 
> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.

@aivanov-jdk 
On macOS, popup is shifted up and does not cover the taskbar even without SM. 

> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.

On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817183611

From pchilanomate at openjdk.org  Fri Oct 25 18:39:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:39:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
Message-ID: <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>

On Thu, 24 Oct 2024 03:01:40 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:
>> 
>>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
> 
>> 950:         for (;;) {
>> 951:             boolean unblocked = false;
>> 952:             synchronized (timedWaitLock()) {
> 
> Where is the overall design of the timed-wait protocol and it use of synchronization described?

When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381

From pchilanomate at openjdk.org  Fri Oct 25 18:50:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>

On Fri, 25 Oct 2024 00:26:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>
Yes.

> src/hotspot/share/classfile/javaClasses.cpp line 2086:
> 
>> 2084:   jboolean vthread_on_list = Atomic::load(addr);
>> 2085:   if (!vthread_on_list) {
>> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);
> 
> It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

The same example mentioned above, with a different timing, could result in two threads trying to add the same virtual thread to the list at the same time.

> src/hotspot/share/code/nmethod.cpp line 711:
> 
>> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> Suggestion:
> 
>   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
>       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 1140:
> 
>> 1138: }
>> 1139: 
>> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {
> 
> Explanatory comment would be good - thanks.

Added comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1532:
> 
>> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
>> 1531:     // Virtual thread case.
>> 1532:     Trigger->unpark();
> 
> So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

Right.

> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
> 
>> 2026:   // First time we run after being preempted on Object.wait().
>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>> 2028:   // that case remove ourselves from the _WaitSet queue.
> 
> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

> src/hotspot/share/runtime/objectMonitor.cpp line 2054:
> 
>> 2052:   // Mark that we are at reenter so that we don't call this method again.
>> 2053:   node->_at_reenter = true;
>> 2054:   assert(!has_owner(current), "invariant");
> 
> The position of this assert seems odd as it seems to be something that should hold at entry to this method.

Ok, I moved it to the beginning of resume_operation.

> src/hotspot/share/runtime/objectMonitor.hpp line 207:
> 
>> 205: 
>> 206:   static void Initialize();
>> 207:   static void Initialize2();
> 
> Please add comment why this needs to be deferred - and till after what?

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 312:
> 
>> 310:   void      set_successor(JavaThread* thread);
>> 311:   void      set_successor(oop vthread);
>> 312:   void      clear_successor();
> 
> Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 349:
> 
>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
> 
> This no longer looks correct if the waiter is a vthread. ??

It is, we still increment _waiters for the vthread case.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:
> 
>> 108: }
>> 109: 
>> 110: // Returns null if DEFLATER_MARKER is observed.
> 
> Comment needs updating

Updated.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:
> 
>> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
>> 129: // This accessor is called when we really need to know if the owner
>> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.
> 
> Comment needs updating

Updated. Removed the second sentence, seemed redundant.

> src/hotspot/share/runtime/synchronizer.cpp line 670:
> 
>> 668:   // Top native frames in the stack will not be seen if we attempt
>> 669:   // preemption, since we start walking from the last Java anchor.
>> 670:   NoPreemptMark npm(current);
> 
> Don't we still pin for JNI monitor usage?

Only when facing contention on this call. But once we have the monitor we don't.

> src/hotspot/share/runtime/synchronizer.hpp line 172:
> 
>> 170: 
>> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
>> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.
> 
> Comment needs updating

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817192967
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195264
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195487
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196602
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817197017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200025
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200202
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195731
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195899
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200860
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200711

From pchilanomate at openjdk.org  Fri Oct 25 18:50:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>

On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2082:
>> 
>>> 2080: }
>>> 2081: 
>>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {
>> 
>> Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>> 
>> I'm struggling to understand how a thread can already be on this list?
>
>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>
> Yes.

> Some comments here about the operation would be useful.
>
Added a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817193493

From pchilanomate at openjdk.org  Fri Oct 25 18:50:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
Message-ID: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>

On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>>
>> Yes.
>
>> Some comments here about the operation would be useful.
>>
> Added a comment.

> I'm struggling to understand how a thread can already be on this list?
>
With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817194346

From pchilanomate at openjdk.org  Fri Oct 25 18:50:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 18:50:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <4W0X1OrNe43nsePtODBGt0aBs3LNJYaCMhJsPslI-7U=.710243ff-55af-4166-80de-48824662dd68@github.com>

On Fri, 25 Oct 2024 05:25:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add/fix comments for David
>>  - Move condition to new line in nmethod::preserve_callee_argument_oops
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1698:
> 
>> 1696:     // on _WaitSetLock so it's not profitable to reduce the length of the
>> 1697:     // critical section.
>> 1698: 
> 
> Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

Restored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027

From aivanov at openjdk.org  Fri Oct 25 18:55:38 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 25 Oct 2024 18:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
Message-ID: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>

On Fri, 25 Oct 2024 18:30:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The updated test `bug6694823.java` works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> 
>> The popup had to be moved if the security manager didn't allow to call `setAlwaysOnTop(true)`.
>> 
>>> There is a functional issue and for that reason I think it is better to retain this test. Details documented here - [JDK-8342012](https://bugs.openjdk.org/browse/JDK-8342012)
>> 
>> There's no functional issue. The `bug6694823.java` test was designed to pass **with the security manager**.
>> 
>> The `bug6694823.java` test fails without the security manager because the conditions don't hold any more.
>
> @aivanov-jdk 
> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
> 
>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
> 
> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?

The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:

https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902

On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.

At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.

I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.

Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.

Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817205444

From weijun at openjdk.org  Fri Oct 25 19:49:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 19:49:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Comments on `java.security` classes.

Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

I also reviewed files in `conf/security`. Everything looks fine except for the `networkaddress.cache.ttl` security property which still references the Security Manager.

src/java.base/share/classes/java/security/AccessControlContext.java line 32:

> 30: 
> 31: /**
> 32:  * AccessControlContext was used with a SecurityManager for access control decisions

I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

src/java.base/share/classes/java/security/AccessControlContext.java line 141:

> 139:         throws AccessControlException
> 140:     {
> 141:         throw new AccessControlException("");

No message for this exception?

src/java.base/share/classes/java/security/AccessControlException.java line 29:

> 27: 
> 28: /**
> 29:  *

Add a sentence like "This was..."?

src/java.base/share/classes/java/security/Policy.java line 90:

> 88:  *       and subject to removal in a future release. Consequently, this class
> 89:  *       is also deprecated and subject to removal. There is no replacement for
> 90:  *       the Security Manager or this class.

Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

src/java.base/share/classes/java/security/Policy.java line 374:

> 372:      *
> 373:      * @param codesource the CodeSource to which the returned
> 374:      *          PermissionCollection has been granted

Can we say this parameter is ignored? I see some other methods said so.

Same with the other `getPermissions` and `implies`.

src/java.base/share/classes/java/security/SecureClassLoader.java line 1:

> 1: /*

The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?

src/java.base/share/classes/java/security/Security.java line 489:

> 487: 
> 488:     /**
> 489:      * Adds a provider to the next position available..

Two periods at the end.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2395870667
PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438672204
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817189896
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817193883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817194616
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817163586
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817173742
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817050537
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817042605

From asmehra at openjdk.org  Fri Oct 25 20:15:09 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 20:15:09 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <VR90kit4KTifPdSCey9s84rnO5qwy-qmVvT9XeDirZo=.7e56521c-a7a4-4d1b-803e-4f78da72b10b@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 113:

> 111: 
> 112:     if (CDSConfig::is_dumping_aot_linked_classes()) {
> 113:       // Need to call try_add_candidate instead of is_candidate, as this may be called

I think in this version of the code this method is not used before `AOTClassLinker::add_candidates`. Can we switch back to `is_candidate` then?

src/hotspot/share/cds/heapShared.hpp line 298:

> 296:   static SeenObjectsTable *_seen_objects_table;
> 297: 
> 298:   // The "special subgraph" contains all the all archived objects that are reachable

an extra `all` in the comment

src/hotspot/share/classfile/systemDictionaryShared.cpp line 685:

> 683:     InstanceKlass* ik = InstanceKlass::cast(k);
> 684: 
> 685:     if (SafepointSynchronize::is_at_safepoint()) {

Why is this piece of block required?
It calls `is_excluded_class` which reads `DumpTimeClassInfo::_excluded` without checking for `has_checked_exclusion`. That means it can return false (the default value) even for classes that may later be marked for exclusion by `check_for_exclusion(ik, p)`.
<del>On the same note, I think we should add an assert in `DumpTimeClassInfo::is_excluded` that `has_checked_exclusion()` is true.<del>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1816853423
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1816996074
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1817159936

From asmehra at openjdk.org  Fri Oct 25 20:15:10 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Fri, 25 Oct 2024 20:15:10 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <VR90kit4KTifPdSCey9s84rnO5qwy-qmVvT9XeDirZo=.7e56521c-a7a4-4d1b-803e-4f78da72b10b@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
 <VR90kit4KTifPdSCey9s84rnO5qwy-qmVvT9XeDirZo=.7e56521c-a7a4-4d1b-803e-4f78da72b10b@github.com>
Message-ID: <OCEkuEHXdrRBIS0ZISo4ry8zhUadvIKnJtfSQ-9y3uI=.f6ba51e5-e28b-41a6-b60f-958d46b07660@github.com>

On Fri, 25 Oct 2024 18:08:17 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>>  - disable test that fails with hotspot_runtime_non_cds_mode
>
> src/hotspot/share/classfile/systemDictionaryShared.cpp line 685:
> 
>> 683:     InstanceKlass* ik = InstanceKlass::cast(k);
>> 684: 
>> 685:     if (SafepointSynchronize::is_at_safepoint()) {
> 
> Why is this piece of block required?
> It calls `is_excluded_class` which reads `DumpTimeClassInfo::_excluded` without checking for `has_checked_exclusion`. That means it can return false (the default value) even for classes that may later be marked for exclusion by `check_for_exclusion(ik, p)`.
> <del>On the same note, I think we should add an assert in `DumpTimeClassInfo::is_excluded` that `has_checked_exclusion()` is true.<del>

Does the check `SafepointSynchronize::is_at_safepoint` imply that exclusion checks for all classes have already been done?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1817167862

From honkar at openjdk.org  Fri Oct 25 20:34:40 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 20:34:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
Message-ID: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>

On Fri, 25 Oct 2024 14:36:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
> 
>> 1: /*
> 
> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
> 
> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
> 
> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.

This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085

Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817311600

From sspitsyn at openjdk.org  Fri Oct 25 20:52:29 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 25 Oct 2024 20:52:29 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v12]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: introduce new annotation @JvmtiHideEvents and use it in VirtualThread/Continuation classes to disallow FramePop requests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/bc056ec1..b9d99918

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=10-11

  Stats: 102 lines in 11 files changed: 71 ins; 15 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From rriggs at openjdk.org  Fri Oct 25 21:04:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:04:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java/util/* and corresponding tests.
Logging tests should refactor to eliminate use of doPrivileged(fn);

test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:

> 50: import com.foo.NumberFormatProviderImpl;
> 51: 
> 52: public class PermissionTest{

This test can be deleted entirely. What remains is just constructing each provider impl.
The summary mentions a RuntimePermission and would need to be revised to a new description.

test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:

> 46:             throw new RuntimeException("unexpected resource bundle");
> 47:         }
> 48: 

This main and TestPermission.java duplicate the basic resource location mechanisms.
This test/Main.java an test/TestPermission can be removed entirely.

test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:

> 26:  * @bug 6552961 6558429
> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
> 28:  * @run main PrivilegedCallables

There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:

> 155:     static class Configure {
> 156:         static void setUp(Properties propertyFile) {
> 157:             doPrivileged(() -> {

The doPrivileged() could be factored out.
And callPrivileged().

test/jdk/java/util/logging/FileHandlerPath.java line 149:

> 147:     static class Configure {
> 148:         static void setUp(Properties propertyFile) {
> 149:             doPrivileged(() -> {

doPrivileged() could be refactored; it is no longer necessary.

test/jdk/java/util/logging/FileHandlerPatternExceptions.java line 106:

> 104:     static class Configure {
> 105:         static void setUp(Properties propertyFile) {
> 106:             doPrivileged(() -> {

doPrivileged() is no longer necessary.

test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:

> 38:  * @modules java.base/jdk.internal.access
> 39:  *          java.logging
> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet

Rename these?  What's really being tested, there are no more Applets.

test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:

> 81:      * then the test is considered a success and passes.
> 82:      *
> 83:      * Note that 4sec may not be enough to detect issues if there are some.

Where is this timeout enforced or measured; this is just a comment, not a parameter.

test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:

> 123:     }
> 124: 
> 125:     @Benchmark

Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2396279786
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817269899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817285899
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817291039
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817304993
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817307433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817310090
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817323513
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327555
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817352471

From honkar at openjdk.org  Fri Oct 25 21:12:39 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:12:39 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>

On Fri, 25 Oct 2024 18:08:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
> 
>> 40:         } catch (ServiceConfigurationError sce) {
>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>> 42:             System.out.println("Test Passed");
> 
> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?

When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 

When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
has been updated to expect ServiceConfigurationError.

AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
> 
>> 1: /*
> 
> I believe this test becomes irrelevant without `SecurityManager`.
> 
> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).

Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
I can update the test summary accordingly  -
 **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**

@azuev-java Your thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817371084
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817373529

From mullan at openjdk.org  Fri Oct 25 21:21:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 25 Oct 2024 21:21:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
Message-ID: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>

On Fri, 25 Oct 2024 19:44:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Yes, good point, let me review the class again and see if we can remove some more text or make some adjustments.

> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
> 
>> 30: 
>> 31: /**
>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
> 
> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.

Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
> 
>> 139:         throws AccessControlException
>> 140:     {
>> 141:         throw new AccessControlException("");
> 
> No message for this exception?

I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

> src/java.base/share/classes/java/security/AccessControlException.java line 29:
> 
>> 27: 
>> 28: /**
>> 29:  *
> 
> Add a sentence like "This was..."?

You mean move the first sentence of the deprecated text to here?

> src/java.base/share/classes/java/security/Policy.java line 90:
> 
>> 88:  *       and subject to removal in a future release. Consequently, this class
>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>> 90:  *       the Security Manager or this class.
> 
> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.

Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

> src/java.base/share/classes/java/security/Policy.java line 374:
> 
>> 372:      *
>> 373:      * @param codesource the CodeSource to which the returned
>> 374:      *          PermissionCollection has been granted
> 
> Can we say this parameter is ignored? I see some other methods said so.
> 
> Same with the other `getPermissions` and `implies`.

Yes, good suggestion.

> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 

Yes I think we can remove that text.

> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?

You mean a warning like we have in the `Permission` subclasses?

`URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

> src/java.base/share/classes/java/security/Security.java line 489:
> 
>> 487: 
>> 488:     /**
>> 489:      * Adds a provider to the next position available..
> 
> Two periods at the end.

Will fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438893608
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817327704
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817335403
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817344307
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817362628
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817348142
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817377926
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817314475

From honkar at openjdk.org  Fri Oct 25 21:27:51 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
Message-ID: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>

On Fri, 25 Oct 2024 16:47:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This doubt applies to all the tests which exercise lazy values or similar logic? without and *with* the security manager.
>> 
>> Now, without the security manager, the problematic cases are no longer relevant; the common path *without* the SM remains unchanged and was never an issue.
>> 
>> However, a more thorough analysis is required.
>
> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.

@prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817385564

From rriggs at openjdk.org  Fri Oct 25 21:27:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 25 Oct 2024 21:27:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
Message-ID: <MjiRdWwmMhjnUXIIeDkclBTTnKBLsbxdZzHk-r69OaA=.c8ddefea-bd18-4ed7-8e2a-700860c2f99e@github.com>

On Thu, 24 Oct 2024 13:19:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge
>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>  - Remove println about Security Manager.
>  - Remove unused static variable NEW_PROXY_IN_PKG.
>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>  - Remove hasSM() method and code that calls it, and remove comment about
>    running test manually with SM.
>  - clientlibs: import order
>  - warning-string
>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde

Reviewed java.compiler and corresponding langtools/tools/ tests. lgtm

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2438900946

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Restore use of atPointA in test StopThreadTest.java
 - remove interruptible check from conditional in Object::wait

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/d6313cf7..66d5385f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=10-11

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <_Tc64RU3Q9TuPgc7ThXZGyW7pRCfoTIJKsqbEfyrFzs=.618f372b-d250-4aed-b7ab-31e1061aec8f@github.com>

On Fri, 25 Oct 2024 05:17:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1673:
> 
>> 1671: 
>> 1672:   ContinuationEntry* ce = current->last_continuation();
>> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {
> 
> So IIUC this use of `interruptible` would be explained as follows:
> 
> // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
> // All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
> // this is a regular Object.wait call.

Yes, although the non-interruptible call is coming from ObjectLocker, which already has the NoPreemptMark, so I removed this check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817388840

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
Message-ID: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>

On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1440:
>> 
>>> 1438: }
>>> 1439: 
>>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
>> 
>> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?
>
> If it's always the current thread, then it should be called 'current' imo.

I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389380

From pchilanomate at openjdk.org  Fri Oct 25 21:33:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 25 Oct 2024 21:33:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
Message-ID: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>

On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If it's always the current thread, then it should be called 'current' imo.
>
> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

> If it's always the current thread, then it should be called 'current' imo.
>
The inflating thread is always the current one but it's not always equal to `inflating_thread`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389882

From jlu at openjdk.org  Fri Oct 25 21:56:32 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 25 Oct 2024 21:56:32 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot
Message-ID: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>

A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 



>     ExceptionCheck
>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
> 
>     jboolean ExceptionCheck(JNIEnv *env);
> 
>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21724/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21724&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341788
  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21724.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21724/head:pull/21724

PR: https://git.openjdk.org/jdk/pull/21724

From dlong at openjdk.org  Fri Oct 25 22:12:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 22:12:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
Message-ID: <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>

On Fri, 25 Oct 2024 18:34:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add/fix comments for David
>  - Move condition to new line in nmethod::preserve_callee_argument_oops

test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:

> 28:  *         by reflection API
> 29:  * @library /test/lib/
> 30:  * @requires vm.compMode != "Xcomp"

If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638

From coleenp at openjdk.org  Fri Oct 25 22:39:19 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

Some more comments and questions on the latest commit, mostly minor.

src/hotspot/share/interpreter/oopMapCache.cpp line 268:

> 266:   }
> 267: 
> 268:   int num_oops() { return _num_oops; }

I can't find what uses this from OopMapCacheEntry.

src/hotspot/share/runtime/objectMonitor.cpp line 1150:

> 1148:     if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) {
> 1149:       assert(_recursions == 0, "invariant");
> 1150:       set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.

This is nice you don't have to do this anymore.

src/hotspot/share/runtime/objectMonitor.hpp line 43:

> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 43: // See next_waiter(), first_waiter(), etc.

Also a nice cleanup.  Did you reconcile the JVMTI code?

src/hotspot/share/runtime/objectMonitor.hpp line 71:

> 69:   bool is_wait()           { return _is_wait; }
> 70:   bool notified()          { return _notified; }
> 71:   bool at_reenter()        { return _at_reenter; }

should these be const member functions?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817407075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817419797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420178

From dlong at openjdk.org  Fri Oct 25 22:39:19 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 22:39:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <K0Dq341ibU2CPv8QKU5yMm4WzR8RYk7fU1qvJ5ShZRs=.b67219d8-b08f-42ba-b007-f3bdb6407349@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:

> 189:   // must restore the rfp value saved on enter though.
> 190:   if (use_pop) {
> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));

leave() also calls authenticate_return_address(), which I assume we still want to call here.
How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321

From coleenp at openjdk.org  Fri Oct 25 22:39:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <55lsLMTORxq8uq0DdIEwRvJauCIyfo9YWwLJpwwBejs=.4680c600-fe2d-4d2d-b3a9-bef80a6eec43@github.com>
 <dWj8IDtdd3UZZC2nZSvDZ3J5TUIxTIg1yAY3mZY1i98=.0308e88e-76b6-419a-b00d-ac4ba07ac379@github.com>
 <C-L8sN_XwQ1SS3e4G6zpF26t_3yG-xHVrrISzYKBqMs=.2b4870e8-f12b-47b8-9ba8-fe3281ecefcb@github.com>
Message-ID: <mHKxi5OLZX0oPMqn6app9G5OQcbaOYlcHvumIufOXZQ=.8ce900f0-4c58-4687-a5e9-fca9853ca62d@github.com>

On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 299:
>> 
>>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 299:   // Same as above but uses tid of current as new value.
>> 
>> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?
>
> It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

but we can't change it there to thread_id because then it would be too confusing.  Since it's used for locking, lock_id seems like a good name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420867

From coleenp at openjdk.org  Fri Oct 25 22:39:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 25 Oct 2024 22:39:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
Message-ID: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>

On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.
>
>> If it's always the current thread, then it should be called 'current' imo.
>>
> The inflating thread is always the current one but it's not always equal to `inflating_thread`.

I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817423564

From prr at openjdk.org  Fri Oct 25 22:44:40 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:44:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <tSwEN61gdo0zlJ-Wsw2DRIx1yD_dTIp596vpnWdm0nY=.24b18dd6-e549-4ae1-8638-da8993c22962@github.com>

On Fri, 25 Oct 2024 21:06:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/imageio/spi/AppletContextTest/IIOPluginTest.java line 42:
>> 
>>> 40:         } catch (ServiceConfigurationError sce) {
>>> 41:             System.out.println("Expected ServiceConfigurationError \n" + sce);
>>> 42:             System.out.println("Test Passed");
>> 
>> Previously, `ServiceConfigurationError` wasn't caught and, as far as I understand, wasn't expected; if it were thrown, the test would fail. Why is the logic different now?
>
> When SM is removed, test fails with java.util.ServiceConfigurationError: javax.imageio.spi.ImageReaderSpi:Provider BadReaderPluginSpi not found. This is the expected behavior without SM. 
> 
> When SM is present this error is swallowed because otherwise a erroneous plugin could cause a VM-wide problem. Now that SM is removed, the test (IIOPluginTest.java)
> has been updated to expect ServiceConfigurationError.
> 
> AFAIK, there isn't another test which checks this code path hence it has been repurposed and retained.

Yes, perhaps there's some more general test for this in java.base, but there's nothing wrong with verifying it here, even though it is sort of backward from what the test previously verified.
Probably the test could always have tested both cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817428928

From amenkov at openjdk.org  Fri Oct 25 22:49:31 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 25 Oct 2024 22:49:31 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
Message-ID: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>

The fix enables logging in the test agent to get more details about intermittent failures.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/21725/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21725&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343103
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21725.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21725/head:pull/21725

PR: https://git.openjdk.org/jdk/pull/21725

From prr at openjdk.org  Fri Oct 25 22:55:38 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 25 Oct 2024 22:55:38 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
Message-ID: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>

On Fri, 25 Oct 2024 21:23:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The tests with ?Audit Core Reflection? in their summary fall into this category, we may consider removing them.
>
> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).

I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
But I don't see a problem with keeping the rest of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817433603

From dlong at openjdk.org  Fri Oct 25 23:06:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:06:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <1KPMXYDDC_St1ngjVzSecyHuxoc42y48ykFAKsgmHQs=.68d68376-6a29-46cb-9cac-eea0ccefcc24@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Suggestion:

  f.interpreter_frame_set_last_sp(f.unextended_sp());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593

From dlong at openjdk.org  Fri Oct 25 23:10:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:10:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <5oXp0uwV-tbPCuHPe7Z6czcA24uOxbf0Fm99ArCYT2g=.2c44eb24-e6f5-48fa-ac55-936b1d85aa16@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:

> 131: 
> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");

Suggestion:

  assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076

From dlong at openjdk.org  Fri Oct 25 23:14:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 25 Oct 2024 23:14:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <ud9bGNgGiRVjQiJkBRz8Sw3xKOe7JKVtYLn8aJfLc7o=.b7d44099-cc5f-4ed5-8048-0561c654a7b8@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:

> 157: 
> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).

Suggestion:

  // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).

Isn't that 2 words, not 3?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437

From kizune at openjdk.org  Fri Oct 25 23:23:37 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 25 Oct 2024 23:23:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
Message-ID: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>

On Fri, 25 Oct 2024 21:09:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/sound/midi/Soundbanks/GetSoundBankSecurityException/GetSoundBankSecurityException.java line 1:
>> 
>>> 1: /*
>> 
>> I believe this test becomes irrelevant without `SecurityManager`.
>> 
>> The summary of the test states, ?`MidiSystem.getSoundbank()` throws unexpected `SecurityException`? which couldn't happen if there's no security manager. Also see [JDK-8312535](https://bugs.openjdk.org/browse/JDK-8312535).
>
> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
> I can update the test summary accordingly  -
>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
> 
> @azuev-java Your thoughts?

That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817444639

From weijun at openjdk.org  Fri Oct 25 23:47:43 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 25 Oct 2024 23:47:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>

On Fri, 25 Oct 2024 20:53:23 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 141:
>> 
>>> 139:         throws AccessControlException
>>> 140:     {
>>> 141:         throw new AccessControlException("");
>> 
>> No message for this exception?
>
> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.

I see. Maybe this is enough.

>> src/java.base/share/classes/java/security/AccessControlException.java line 29:
>> 
>>> 27: 
>>> 28: /**
>>> 29:  *
>> 
>> Add a sentence like "This was..."?
>
> You mean move the first sentence of the deprecated text to here?

Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452801
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817452658

From weijun at openjdk.org  Sat Oct 26 00:01:40 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 26 Oct 2024 00:01:40 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>

On Fri, 25 Oct 2024 21:14:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/SecureClassLoader.java line 1:
>> 
>>> 1: /*
>> 
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? Also, `getPermissions` always returns an empty `Permissions` object, do we need to add an `@apiNote` for it?
>
>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
> 
> Yes I think we can remove that text.
> 
>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
> 
> You mean a warning like we have in the `Permission` subclasses?
> 
> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.

Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.

On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817457008

From dlong at openjdk.org  Sat Oct 26 00:06:16 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:06:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
 <PJi9qJgboaDhtpeyHTuAaMbsvmCccehWuSbxpuKNiS8=.6187fb8d-5b12-4892-8747-792e8f2b3770@github.com>
Message-ID: <jiLbxr6TkMLG8JgH0CHhoJpkggmJZjyxoWVBLU8Frgk=.d3c668c3-adf5-4fb6-88c4-75b710e8f6f8@github.com>

On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
>> 
>>> 298:   CodeBlob* cb = top.cb();
>>> 299: 
>>> 300:   if (cb->frame_size() == 2) {
>> 
>> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.
>
> We could also check the caller of the runtime frame, something like:
> 
> #ifdef ASSERT
>   RegisterMap map(JavaThread::current(),
>                   RegisterMap::UpdateMap::skip,
>                   RegisterMap::ProcessFrames::skip,
>                   RegisterMap::WalkContinuation::skip);
>   frame caller = top.sender(&map);
>   assert(caller.is_compiled_frame(), "");
>   assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
> #endif
> 
> Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

I agree, checking for frame_size() == 2 seems fragile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817458483

From dlong at openjdk.org  Sat Oct 26 00:20:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:20:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:

> 186:   // Avoid using a leave instruction when this frame may
> 187:   // have been frozen, since the current value of rfp
> 188:   // restored from the stub would be invalid. We still

It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936

From dlong at openjdk.org  Sat Oct 26 00:30:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:30:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:

> 308:     sp -= 2;
> 309:     sp[-2] = sp[0];
> 310:     sp[-1] = sp[1];

This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371

From dlong at openjdk.org  Sat Oct 26 00:33:17 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 00:33:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:

> 336:   // Make sure that extended_sp is kept relativized.
> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()

Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037

From amenkov at openjdk.org  Sat Oct 26 00:46:06 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Sat, 26 Oct 2024 00:46:06 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v12]
In-Reply-To: <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>
Message-ID: <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>

On Fri, 25 Oct 2024 20:52:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: introduce new annotation @JvmtiHideEvents and use it in VirtualThread/Continuation classes to disallow FramePop requests

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.

(c) 2024

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 38:

> 36:  *
> 37:  * @implNote
> 38:  * This annotation is only used for the VirtualThread notifyJvmti*  methods.

What about VirtualThread.switchToCarrierThread and VirtualThread.switchToVirtualThread ? They also have the annotation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817470128
PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817469168

From zgu at openjdk.org  Sat Oct 26 01:39:15 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sat, 26 Oct 2024 01:39:15 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
Message-ID: <p7YVH0moyGyDlINK9wVZK4n-7Z5KCyI6kvmX8wkcgWs=.35c31ce4-595f-48a0-9902-6db8a3a70738@github.com>

On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8342560: GenShen: Fix confusing method name
>    
>    Reviewed-by: ysr
>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>    
>    Reviewed-by: xpeng, ysr
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>    
>    Reviewed-by: kdnilsen, ysr
>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>    
>    Reviewed-by: ysr
>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>    
>    Reviewed-by: ysr
>  - 8342255: GenShen: Remove unnecessary enum initial values
>    
>    Reviewed-by: ysr
>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 243:

> 241: void ShenandoahAgeCensus::update_tenuring_threshold() {
> 242:   if (!ShenandoahGenerationalAdaptiveTenuring) {
> 243:     _tenuring_threshold[_epoch] = InitialTenuringThreshold;

`InitialTenuringThreshold` is currently only used by parallel GC, so that the flag's constraint is only implemented in parallel GC [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp#L177) . Now, Shenandoah reuses the flag, you may want to consider to parallel GC's implementation into `shared`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1817529349

From dlong at openjdk.org  Sat Oct 26 01:45:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:45:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:

> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 1554:   adr(rscratch1, resume_pc);
> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));

Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:

> 1565: 
> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
> 1567:   bind(resume_pc);

If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657

From dlong at openjdk.org  Sat Oct 26 01:54:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:54:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:

> 117:   return  mask.num_oops()
> 118:         + 1 // for the mirror oop
> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot

Where is this temp oop slot set and used?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144

From dlong at openjdk.org  Sat Oct 26 01:57:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 01:57:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:

> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
> 3795:   __ testbool(rscratch1);
> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);

If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633

From dlong at openjdk.org  Sat Oct 26 02:01:18 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 02:01:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
Message-ID: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
> 
>> 308:     sp -= 2;
>> 309:     sp[-2] = sp[0];
>> 310:     sp[-1] = sp[1];
> 
> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

Could the problem be solved with a resume adapter instead, like the interpreter uses?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817556946

From zgu at openjdk.org  Sat Oct 26 02:08:16 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sat, 26 Oct 2024 02:08:16 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
Message-ID: <Rku187KbA-0dpP0fxJhyUnvODEyUPjHLWlEgkS-KGEU=.36fd6343-7cdd-4168-9944-fa52552139d2@github.com>

On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
> 
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - Merge
>  - 8342560: GenShen: Fix confusing method name
>    
>    Reviewed-by: ysr
>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>    
>    Reviewed-by: xpeng, ysr
>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>    
>    Reviewed-by: kdnilsen, ysr
>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>    
>    Reviewed-by: ysr
>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>    
>    Reviewed-by: ysr
>  - 8342255: GenShen: Remove unnecessary enum initial values
>    
>    Reviewed-by: ysr
>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 701:

> 699:       // Seed the collection set with resource area-allocated
> 700:       // preselected regions, which are removed when we exit this scope.
> 701:       ResourceMark rm;

You can fold `ResourceMark` into `ShenandoahCollectionSetPreselector` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1817564685

From dlong at openjdk.org  Sat Oct 26 02:18:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Sat, 26 Oct 2024 02:18:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

> On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.

During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub.  In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320

From jwaters at openjdk.org  Sat Oct 26 04:31:11 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 26 Oct 2024 04:31:11 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
Message-ID: <ljJ5fgAFM5Ha4J1jCY-4K2lPuRNRqBFSb1nrx2C2aDo=.90089207-5868-48eb-8158-7aa459c516ce@github.com>

On Thu, 24 Oct 2024 14:22:28 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8342682

Turns out jpackage is part of core libs

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2439318255

From jwaters at openjdk.org  Sat Oct 26 04:38:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 26 Oct 2024 04:38:05 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
Message-ID: <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>

On Thu, 24 Oct 2024 14:22:28 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8342682

I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2439331318

From alanb at openjdk.org  Sat Oct 26 05:16:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Oct 2024 05:16:06 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v12]
In-Reply-To: <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>
 <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>
Message-ID: <C8vyIYHXsZqxdbwzE-viyGY_b7KcqCrkzrMNYTl7-z8=.8c8a6778-e8b2-4e47-9fcd-cf5a33c96671@github.com>

On Sat, 26 Oct 2024 00:41:43 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: introduce new annotation @JvmtiHideEvents and use it in VirtualThread/Continuation classes to disallow FramePop requests
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 38:
> 
>> 36:  *
>> 37:  * @implNote
>> 38:  * This annotation is only used for the VirtualThread notifyJvmti*  methods.
> 
> What about VirtualThread.switchToCarrierThread and VirtualThread.switchToVirtualThread ? They also have the annotation.

We working to remove these two methods. I think the main thing for JvmtiMountTransition is that the interface description provides enough information to know when the annotation is needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817689498

From alanb at openjdk.org  Sat Oct 26 05:42:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 26 Oct 2024 05:42:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v11]
In-Reply-To: <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <S4BG6mJ82p0RbHdnGDmlTRwBfYq-sgQBFh4bN_hHJ_s=.b8b496a0-214e-406b-a1bc-be66538065b2@github.com>
 <5jSeha08dbdSzkrOaxjdhrHaYFZi_cFXYA-5ZKmNmnk=.a22af9ce-572d-4cef-88b3-509324268484@github.com>
Message-ID: <_BwEZ3vYJTCgODZ_cvAQ49Vz00neenp7mMxrPo7jg-8=.60dab023-3df4-4533-bd6d-89dace99d65a@github.com>

On Fri, 25 Oct 2024 22:09:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add/fix comments for David
>>  - Move condition to new line in nmethod::preserve_callee_argument_oops
>
> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:
> 
>> 28:  *         by reflection API
>> 29:  * @library /test/lib/
>> 30:  * @requires vm.compMode != "Xcomp"
> 
> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430

From sspitsyn at openjdk.org  Sat Oct 26 06:09:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 26 Oct 2024 06:09:06 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v12]
In-Reply-To: <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>
 <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>
Message-ID: <AGhyt3kXHd3X812ovNAt50O8qNe6POA0By7AbrCHi78=.b28b057e-7376-4732-a170-9e7e023ea42d@github.com>

On Sat, 26 Oct 2024 00:43:00 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: introduce new annotation @JvmtiHideEvents and use it in VirtualThread/Continuation classes to disallow FramePop requests
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> (c) 2024

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817695834

From sspitsyn at openjdk.org  Sat Oct 26 06:16:06 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 26 Oct 2024 06:16:06 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v12]
In-Reply-To: <C8vyIYHXsZqxdbwzE-viyGY_b7KcqCrkzrMNYTl7-z8=.8c8a6778-e8b2-4e47-9fcd-cf5a33c96671@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <gz9rhGyN-B34h74tV1OmqvpIbySh6dkv5XkUtIun2k4=.0be097ba-78f3-4f16-928d-3e76541eab41@github.com>
 <1AiBASJOG5Ld7F-Q7tyJGDRv_xh7E2e0YWvvq2RSf4U=.6c7618ce-e4ed-4f71-b510-0da67a1421ea@github.com>
 <C8vyIYHXsZqxdbwzE-viyGY_b7KcqCrkzrMNYTl7-z8=.8c8a6778-e8b2-4e47-9fcd-cf5a33c96671@github.com>
Message-ID: <6dl-NY7azZxKQQgPe25gjCmsQivwghwW-o7DpxiWVxk=.588717d7-43ee-4c3a-ac15-78829846bacd@github.com>

On Sat, 26 Oct 2024 05:13:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 38:
>> 
>>> 36:  *
>>> 37:  * @implNote
>>> 38:  * This annotation is only used for the VirtualThread notifyJvmti*  methods.
>> 
>> What about VirtualThread.switchToCarrierThread and VirtualThread.switchToVirtualThread ? They also have the annotation.
>
> We working to remove these two methods. I think the main thing for JvmtiMountTransition is that the interface description provides enough information to know when the annotation is needed.

Good catch, thanks. These two methods are impacted by temporary VTMS transitions.
I've restored as it was before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817696831

From sspitsyn at openjdk.org  Sat Oct 26 06:37:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 26 Oct 2024 06:37:07 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
 <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>
Message-ID: <UpiAUMlQ0zi4vlhOxKPgECTn-Z0bFBSJyCMi46bz07M=.3bd77cb4-6cf1-4995-affc-e359e9d7d35d@github.com>

On Thu, 24 Oct 2024 22:58:01 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 asserts from continuationFreezeThaw.cpp again
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 667:
> 
>> 665: 
>> 666: javaVFrame*
>> 667: JvmtiEnvBase::check_and_skip_hidden_frames(bool is_in_VTMS_transition, javaVFrame* jvf) {
> 
> reworked function looks much better! Now it's clear what the function does and I have a question what it should do.
> The function checks `@JvmtiMountTransition` annotation first even if the thread is in transition.
> If `@JvmtiMountTransition` is present, the code doesn't care about `@ChangesCurrentThread` (and doesn't case about `@JvmtiMountTransition` if in_transition + `@ChangesCurrentThread`).
> But we have 2 methods in VirtualThread class (`switchToCarrierThread()` and `switchToVirtualThread()`) with both annotations.
> So if the function is called when `switchToCarrierThread` is on top, the function skips this frame, but if the thread calls some other function without `@JvmtiMountTransition` annotation from `switchToCarrierThread`, the function returns `switchToCarrierThread`.

Good catch, thanks.
These two functions are impacted by temporary VTMS transitions. It seems we fail to hide frames in these transitions while we skip the JVMTI events in their context. I'll try to fix this issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817699939

From sspitsyn at openjdk.org  Sat Oct 26 06:43:05 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 26 Oct 2024 06:43:05 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <UpiAUMlQ0zi4vlhOxKPgECTn-Z0bFBSJyCMi46bz07M=.3bd77cb4-6cf1-4995-affc-e359e9d7d35d@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
 <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>
 <UpiAUMlQ0zi4vlhOxKPgECTn-Z0bFBSJyCMi46bz07M=.3bd77cb4-6cf1-4995-affc-e359e9d7d35d@github.com>
Message-ID: <oIA2BbAM67QClHaoADOTGTMK4_2jqaQIkT4YEx-abik=.d10d38d9-6f6b-4190-8a79-984909a07533@github.com>

On Sat, 26 Oct 2024 06:34:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 667:
>> 
>>> 665: 
>>> 666: javaVFrame*
>>> 667: JvmtiEnvBase::check_and_skip_hidden_frames(bool is_in_VTMS_transition, javaVFrame* jvf) {
>> 
>> reworked function looks much better! Now it's clear what the function does and I have a question what it should do.
>> The function checks `@JvmtiMountTransition` annotation first even if the thread is in transition.
>> If `@JvmtiMountTransition` is present, the code doesn't care about `@ChangesCurrentThread` (and doesn't case about `@JvmtiMountTransition` if in_transition + `@ChangesCurrentThread`).
>> But we have 2 methods in VirtualThread class (`switchToCarrierThread()` and `switchToVirtualThread()`) with both annotations.
>> So if the function is called when `switchToCarrierThread` is on top, the function skips this frame, but if the thread calls some other function without `@JvmtiMountTransition` annotation from `switchToCarrierThread`, the function returns `switchToCarrierThread`.
>
> Good catch, thanks.
> These two functions are impacted by temporary VTMS transitions. It seems we fail to hide frames in these transitions while we skip the JVMTI events in their context. I'll try to fix this issue.

I'd suggest to file a separate bug on this issue as it has to be tested well.
Please, let me know if you are okay with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1817700598

From rrich at openjdk.org  Sat Oct 26 06:54:16 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 06:54:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
Message-ID: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>

On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
> 
>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 1554:   adr(rscratch1, resume_pc);
>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
> 
> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

Its indeed difficult to see how the value is propagaged. I think it goes like this:

- read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
- copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
- Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
- Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702223

From rrich at openjdk.org  Sat Oct 26 06:59:19 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 06:59:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
Message-ID: <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>

On Sat, 26 Oct 2024 01:42:17 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
> 
>> 1565: 
>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>> 1567:   bind(resume_pc);
> 
> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.

At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986

From rrich at openjdk.org  Sat Oct 26 07:07:20 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Sat, 26 Oct 2024 07:07:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
Message-ID: <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>

On Sat, 26 Oct 2024 01:54:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
> 
>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>> 3795:   __ testbool(rscratch1);
>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
> 
> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994

From sspitsyn at openjdk.org  Sun Oct 27 02:51:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 27 Oct 2024 02:51:04 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v13]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <fena8CGmRqGzMfL6aPPF6yweQTwq-SXQeguDOiYortA=.826e3fc3-0746-4d2a-86ec-533f05678496@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: refactor VM_VirtualThreadGetOrSetLocal::get_java_vframe; tweak anotation description; restore continuation asserts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/b9d99918..c75836cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=11-12

  Stats: 27 lines in 4 files changed: 5 ins; 20 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From jwaters at openjdk.org  Sun Oct 27 06:25:02 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 27 Oct 2024 06:25:02 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v3]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>

> 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 two additional commits since the last revision:

 - Merge branch 'master' into unused
 - 8342682

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/2294b27f..cd57fc6c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=01-02

  Stats: 30419 lines in 377 files changed: 9472 ins; 19545 del; 1402 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From sspitsyn at openjdk.org  Sun Oct 27 21:45:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sun, 27 Oct 2024 21:45:08 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v14]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  remove newly added trailing space

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/c75836cf..22e8ab7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From dholmes at openjdk.org  Mon Oct 28 00:29:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:29:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
Message-ID: <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>

On Fri, 25 Oct 2024 18:36:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
>> 
>>> 950:         for (;;) {
>>> 951:             boolean unblocked = false;
>>> 952:             synchronized (timedWaitLock()) {
>> 
>> Where is the overall design of the timed-wait protocol and it use of synchronization described?
>
> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

Thanks for the explanation but that needs to be documented somewhere.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510

From dholmes at openjdk.org  Mon Oct 28 00:34:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:34:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
Message-ID: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.9a170591-0b33-4424-8e01-09f39d936273@github.com>

On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 174:
>> 
>>> 172: 
>>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
>> 
>> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??
>
> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.
> 
> 
> $ grep -r JFR_THREAD_ID
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
> runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
> runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
> runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543

From dholmes at openjdk.org  Mon Oct 28 00:34:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:34:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>

On Fri, 25 Oct 2024 18:42:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 349:
>> 
>>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
>> 
>> This no longer looks correct if the waiter is a vthread. ??
>
> It is, we still increment _waiters for the vthread case.

Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368

From dholmes at openjdk.org  Mon Oct 28 00:41:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:41:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
Message-ID: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>

On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
>> 
>>> 2026:   // First time we run after being preempted on Object.wait().
>>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>>> 2028:   // that case remove ourselves from the _WaitSet queue.
>> 
>> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.
>
> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

The first sentence is not a sentence. Is it supposed to be saying:

// The first time we run after being preempted on Object.wait()
// we check if we were interrupted or the wait timed-out ...

?

>> src/hotspot/share/runtime/synchronizer.cpp line 670:
>> 
>>> 668:   // Top native frames in the stack will not be seen if we attempt
>>> 669:   // preemption, since we start walking from the last Java anchor.
>>> 670:   NoPreemptMark npm(current);
>> 
>> Don't we still pin for JNI monitor usage?
>
> Only when facing contention on this call. But once we have the monitor we don't.

But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818239594
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013

From dholmes at openjdk.org  Mon Oct 28 00:41:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:41:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>

On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> If it's always the current thread, then it should be called 'current' imo.
>>>
>> The inflating thread is always the current one but it's not always equal to `inflating_thread`.
>
> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240440

From dholmes at openjdk.org  Mon Oct 28 00:47:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 00:47:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
Message-ID: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>

On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Some comments here about the operation would be useful.
>>>
>> Added a comment.
>
>> I'm struggling to understand how a thread can already be on this list?
>>
> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015

From dholmes at openjdk.org  Mon Oct 28 01:02:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:02:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>

On Fri, 25 Oct 2024 13:11:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
>> 
>>> 1548: #endif /* ASSERT */
>>> 1549: 
>>> 1550:   push_cont_fastpath();
>> 
>> One of the callers of this gives a clue what it does.
>> 
>>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
>> 
>> Why do you do this here?  Oh please more comments...
>
> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245043

From dholmes at openjdk.org  Mon Oct 28 01:02:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:02:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
Message-ID: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>

On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I'm struggling to understand how a thread can already be on this list?
>>>
>> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.
>
> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776

From dholmes at openjdk.org  Mon Oct 28 01:16:00 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 01:16:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:

> 2380:   __ bind(after_transition);
> 2381: 
> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {

It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880

From dholmes at openjdk.org  Mon Oct 28 03:16:31 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 28 Oct 2024 03:16:31 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot
In-Reply-To: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
Message-ID: <bp0k-FpfayXSHao6bRxJjZs1hmeNh4_lkt_XR5JVNY0=.4f1e3054-8065-4cc9-939f-d2ebb92004e4@github.com>

On Fri, 25 Oct 2024 21:51:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 
> 
> 
> 
>>     ExceptionCheck
>>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
>> 
>>     jboolean ExceptionCheck(JNIEnv *env);
>> 
>>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

@justin-curtis-lu  you have missed a large number of usages:

./share/prims/nativeEntryPoint.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/prims/upcallLinker.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/prims/unsafe.cpp:  if (env->ExceptionOccurred()) {
./share/prims/upcallStubs.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
./share/runtime/continuation.cpp:    guarantee(!env->ExceptionOccurred(), "register jdk.internal.vm.Continuation natives");


Thanks

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21724#pullrequestreview-2397848145

From alanb at openjdk.org  Mon Oct 28 05:58:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Oct 2024 05:58:38 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v14]
In-Reply-To: <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>
Message-ID: <uMmIXw5kTZKG3gn4mJXdreadf7Ys2FXFHfyVR1wacSQ=.f737b830-b339-493a-9246-1c445e8b6464@github.com>

On Sun, 27 Oct 2024 21:45:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove newly added trailing space

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 32:

> 30: /**
> 31:  * A method may be annotated with JvmtiHideEvents to hint it is not
> 32:  * desirable to sent JVMTI events in context of the annotated method.

s/sent/send/ 

Also might be cleaerr to drop "not desirable" from the sentence as it begs too many questions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1818413397

From rrich at openjdk.org  Mon Oct 28 07:59:07 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 07:59:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:

> 600: 
> 601:   address generate_cont_preempt_stub();
> 602:   address generate_cont_resume_monitor_operation();

The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

src/hotspot/share/runtime/synchronizer.cpp line 1559:

> 1557:         // and set the stack locker field in the monitor.
> 1558:         m->set_stack_locker(mark.locker());
> 1559:         m->set_anonymous_owner();  // second

Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818523530
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820

From alanb at openjdk.org  Mon Oct 28 09:21:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 28 Oct 2024 09:21:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
 <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>
Message-ID: <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@github.com>

On Mon, 28 Oct 2024 00:26:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.
>
> Thanks for the explanation but that needs to be documented somewhere.

The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426

From yzheng at openjdk.org  Mon Oct 28 10:39:43 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 28 Oct 2024 10:39:43 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:

> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
> 328:                                                                                                                                      \
> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \

to make the type assert more precise:

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 20b9609cdbf..f2b8a69c03f 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -326,7 +326,7 @@
                                                                                                                                      \
   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
                                                                                                                                      \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
   volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
   volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
   volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
index 86d7277f88b..0492f28e15b 100644
--- a/src/hotspot/share/runtime/vmStructs.cpp
+++ b/src/hotspot/share/runtime/vmStructs.cpp
@@ -786,8 +786,8 @@
                                                                                                                                      \
   volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
   unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /* NOTE: no type */    \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
-  unchecked_nonstatic_field(ObjectMonitor,     _stack_locker,                                 BasicLock*)                            \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \
   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
   volatile_nonstatic_field(BasicLock,          _metadata,                                     uintptr_t)                             \
   nonstatic_field(ObjectMonitor,               _contentions,                                  int)                                   \

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818818274

From coleenp at openjdk.org  Mon Oct 28 12:03:46 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 12:03:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
Message-ID: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>

On Mon, 28 Oct 2024 00:38:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.
>
> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818935916

From mullan at openjdk.org  Mon Oct 28 12:29:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 12:29:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Specify that params passed to getPermissions and implies are ignored and
   implies always returns false.
 - Change deprecated annotations to api notes on getPolicy and setPolicy.
 - clientlibs: Updated Problemlist
   Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
 - clientlibs: Deleted JPopupMenu tests
   The following tests are deleted as they don't hold value without SM
   test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
   always-on-top for apps which doesn't hold value after SM removal.
   
   test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
   Works differently on macOS and windows & linux but this is the expected behavior.
   Details in JDK-8342012. Not a functional issue.
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
 - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
   test renamed, test summary updated
 - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
 - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
 - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
 - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=03
  Stats: 65873 lines in 1867 files changed: 1158 ins; 61009 del; 3706 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From rrich at openjdk.org  Mon Oct 28 13:10:44 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 13:10:44 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/share/runtime/objectMonitor.hpp line 202:

> 200: 
> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
> 202:   BasicLock* volatile _stack_locker;

IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029

From rrich at openjdk.org  Mon Oct 28 13:18:15 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 28 Oct 2024 13:18:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
Message-ID: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>

On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/runtime/objectMonitor.hpp line 202:
> 
>> 200: 
>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>> 202:   BasicLock* volatile _stack_locker;
> 
> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

`ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819034645

From rsunderbabu at openjdk.org  Mon Oct 28 13:39:22 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 28 Oct 2024 13:39:22 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v3]
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <O5ieKAQBy-KOiVuVh_0zz1i8Du01iZRH_ExmlYWG55k=.58e10cf4-a5d9-4c66-82c2-6ca09b534986@github.com>

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  remove separate OOM handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21641/files
  - new: https://git.openjdk.org/jdk/pull/21641/files/b3d9da8d..2d5ce321

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21641/head:pull/21641

PR: https://git.openjdk.org/jdk/pull/21641

From mullan at openjdk.org  Mon Oct 28 13:47:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 13:47:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <MTCeVNXJUnrTJA3ZefUJ88iys7Qk6qimf2LAYiZfPYw=.74cb9249-a5be-416c-878d-b3ed1c09feb6@github.com>
 <_UQk_rXNduHRZLxx3Y5n9iIW8AIxddeMhTW-9HaU3W8=.1903abd6-c56e-4096-bf3a-4b48ed890c0d@github.com>
Message-ID: <t3eNL3sIsaBSuCKWvllA_vjpUyR7fH2u7cy2j_lCESE=.7a06982d-f836-4a2a-a711-418df3b180ae@github.com>

On Tue, 15 Oct 2024 22:09:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/URLClassLoader.java line 667:
>> 
>>> 665:      * @param codesource the codesource
>>> 666:      * @throws    NullPointerException if {@code codesource} is {@code null}.
>>> 667:      * @return the permissions for the codesource
>> 
>> Since there is no SecurityManager any more, I guess this method could be, in the future, degraded to return an empty collection? Then when that's done the API documentation above could be trivially simplified to `{@return an empty {@code PermissionCollection}}`?
>
> Yes, I think that is a good suggestion. Let me think about whether it should be done as part of this JEP or if we can do it later.

I filed a follow-on issue to consider this: https://bugs.openjdk.org/browse/JDK-8343150

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819084510

From mullan at openjdk.org  Mon Oct 28 14:03:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
Message-ID: <vVe4o9wGohQAxFryEEG-ATg99g8s9Lud9YlM68S4BZc=.bcaa09df-a01d-4751-af7d-245fb008881c@github.com>

On Tue, 22 Oct 2024 20:20:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.base/share/classes/java/io/FilePermission.java line 71:
> 
>> 69:  *
>> 70:  * @apiNote
>> 71:  * This permission cannot be used for controlling access to resources anymore
> 
> The word "anymore" is unnecessary.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819108633

From mullan at openjdk.org  Mon Oct 28 14:03:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <Iw9TPN7t0-P1oDaJ34UyaUvFFG4DsVz3WXCm5zupkhI=.706de8c9-6200-4b5c-913b-d9331e100f55@github.com>
 <w_0krrE07APnILIvtx1O8Inrcj6fXKxjdvW8t-ZCx_o=.7beedb8c-7529-4483-88f0-ec8f2534e180@github.com>
Message-ID: <0zzRwrMnjzNfCdMIUBA1pBgjiUjutknxWCyGtlODbto=.ad858095-07aa-41f9-a3f3-9f1059ac5b5c@github.com>

On Fri, 25 Oct 2024 13:44:56 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/SerializablePermission.java line 40:
>> 
>>> 38:  *
>>> 39:  * @apiNote
>>> 40:  * This permission cannot be used for controlling access to resources anymore
>> 
>> Unnecessary "anymore"
>
> Removed this word from all `Permission` subclasses; fix will be in next update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/44b552adb68d9aae1e72ed7bf20feb81552014c8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819109553

From mullan at openjdk.org  Mon Oct 28 14:03:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:05 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <zDUFT6HqWSXMH3_4T_2xrlo8lfiiDnDtZRsnwEgciPs=.27b968be-aefa-4e96-80dd-fcad60fbcbb0@github.com>
Message-ID: <MCGUYtIT23K7W16rxcBd1daw9mpMeqYpQ8Hki50NKaQ=.0f8f8488-24be-441e-9195-a9ddb63b3b69@github.com>

On Mon, 21 Oct 2024 22:57:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> test/jdk/java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java line 338:
> 
>> 336: 
>> 337:     public static enum TestCase {
>> 338:         UNSECURE;
> 
> Better to drop this enum entirely.   Simply call `FieldSetAccessibleTest::run` as it's the only test case.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/e50cf64d771ed12de20e0a0500dc92f2e8a0abe4

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819096279

From mullan at openjdk.org  Mon Oct 28 14:03:08 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:08 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <VS3HHbLf4v4TKw8Bd9JQ643bQeKitbyS6NUmrfDyH4w=.67267be0-b748-4a02-ae91-91d78ed79961@github.com>
 <20itE1cB8nTYacBoa8CGuHwGj8h0BX7A2eKTQmjFFdM=.07cfb10b-ce49-4951-8474-5f1a641edec5@github.com>
Message-ID: <0WKxUeUG7NcPFjIQDAKyMj2Q-zqjGzuDbgojtkuu-LA=.fbf49390-45aa-4238-84c7-ff8e18bdf74c@github.com>

On Tue, 22 Oct 2024 21:01:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/UIDefaults/6795356/TableTest.java line 45:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> I guess we can test this without SM since it tests SwingLazyValue?
>
> I believe I had removed this test because it wasn't testing anything significant. But I have re-added it please re-review and let me know if it holds value to be retained.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819105638

From mullan at openjdk.org  Mon Oct 28 14:03:06 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:03:06 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DO6AvL62_TojRe_nQIJZ4OmMU-FP4JUnKqorGLqdyC8=.415589e1-0c96-4628-8731-89c61f216c3a@github.com>
 <r7PgwCC9eQF6AeE3l5Xw1g76uBBKbZOaxBVG4kODVQ8=.0cebc83f-ae31-40d6-b120-0a2becfc6b48@github.com>
Message-ID: <fTgvcpw5HqiI30y5Z2jb5QjrdO2A7ZB-xKxi-elxDoo=.f9a20ad6-15ca-45ba-8d0d-09eef26f2df8@github.com>

On Tue, 22 Oct 2024 20:55:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JEditorPane/8080972/TestJEditor.java line 49:
>> 
>>> 47:         SwingUtilities.invokeAndWait(TestJEditor::testJEditorPane);
>>> 48:     }
>>> 49: 
>> 
>> Is there any need to catch the exception and rethrow RuntimeException below? I think we can remove try-catch block altogether...
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

>> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java line 117:
>> 
>>> 115:             }
>>> 116:             popup.setVisible(false);
>>> 117:             frame.dispose();
>> 
>> The error condition is checked and exception thrown before disposing the frame and popup, guess this 2 should be in finally block..
>
> Updated

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/d9ee496f7349cb8beaf1e696fd430f8064baee8e

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819100037
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819104451

From mullan at openjdk.org  Mon Oct 28 14:08:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:08:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <DrO4IG-LRHDPPPkg0V-cOzm8wGSxKFg4_4Q-_pk91AI=.fec8bb70-6c72-441e-b29f-b18b9fb7f683@github.com>
 <LgHahJcOWIQsiTfs6mgjmA9bDob7JXeeFkyt8uN5vuA=.39bcfcfc-bfca-473c-ab8b-d69e5c6bf645@github.com>
Message-ID: <Fq8YAL6u5aQpBWsTKacnyqmH2to-keqqUMZlRfCMUU4=.4267c4b9-3527-463b-a5d4-8e582ccf0dd5@github.com>

On Wed, 23 Oct 2024 13:07:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/websocket/security/WSURLPermissionTest.java line 342:
>> 
>>> 340:         throws Exception
>>> 341:     {
>>> 342:         action.run();
>> 
>> testWithNoSecurityManager was previously a sanity check, the test was focused on permission check. Is the test still useful to keep, maybe it would be renamed or the test method renamed?
>
> Good point. Similarly, the URLPermission[] parameter is now always unused, so maybe I should get rid of that too.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/82bb0d8207334d6072277e596fb16228f397fb77 and https://github.com/openjdk/jdk/pull/21498/commits/34439751f1b26e6ff1705e35f269e260401233af

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819119422

From mullan at openjdk.org  Mon Oct 28 14:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <ggccis0uu3BN3Kmofv1RlWFK8QykntW4i06p84FMTy8=.58430444-17a6-4a6e-b983-92588d6e21d5@github.com>

On Fri, 25 Oct 2024 20:34:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 489:
>> 
>>> 487: 
>>> 488:     /**
>>> 489:      * Adds a provider to the next position available..
>> 
>> Two periods at the end.
>
> Will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ed0f5c07f2bf3f3d7636533a77e8455d66bbf8b8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819146725

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>

On Thu, 24 Oct 2024 15:01:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1612:
> 
>> 1610:      * obtained.  The {@code String} value of this property is then
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * specification of {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819134820

From mullan at openjdk.org  Mon Oct 28 14:16:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:16:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <LpTIZkhYkAmFAbKSC_sz-_2ZlKTGOGMPgycEsLyelT8=.96bb2a6b-d654-4971-b887-7a79be6f9963@github.com>
Message-ID: <_-G-fWk2aAwcuoiLUlzkkNJ5ShuRx8dAOtOGfL1c9IE=.777bfd82-b0a6-43f3-a761-c9bcfe962553@github.com>

On Thu, 24 Oct 2024 19:33:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.rmi/share/classes/sun/rmi/server/LoaderHandler.java line 342:
> 
>> 340:         /*
>> 341:          * There is no security manager, so disable access to RMI class
>> 342:          * loaders and use the would-de parent instead.
> 
> Fix typo "would-de" -> "would-be".

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0f448e5fabac7941cd1b551aa1cc9ade773814ff

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819144885

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <GjxEiU7FQ9j_4EDb6nAwuApuvgHg6nlgwF-nGm0N5-w=.bf1d5c89-f5df-4a6c-aeed-50c382b5dd3c@github.com>

On Fri, 25 Oct 2024 20:48:14 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessControlContext.java line 32:
>> 
>>> 30: 
>>> 31: /**
>>> 32:  * AccessControlContext was used with a SecurityManager for access control decisions
>> 
>> I'm not sure how you use this name elsewhere. To me, one either uses "Security Manager" as the name for the technique or `SecurityManager` (inside `{@code}`) as the name for the class.
>
> Right, it should be "the Security Manager", but we can also link to the `SecurityManager` class as plain text.  I'll make some wording changes to this class and `AccessController`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/275dabd4dbc8f443901dc5d82b281111dcbf15e6

>> src/java.base/share/classes/java/security/Policy.java line 374:
>> 
>>> 372:      *
>>> 373:      * @param codesource the CodeSource to which the returned
>>> 374:      *          PermissionCollection has been granted
>> 
>> Can we say this parameter is ignored? I see some other methods said so.
>> 
>> Same with the other `getPermissions` and `implies`.
>
> Yes, good suggestion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/4981da0fe50919e60cc036371f8bc8d7ee153849

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819165566
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819166630

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <glbOlTeDA4rr6kTYwV5hYzPxLyS1cpvKRTbspJeMl1w=.7d51e813-3975-4cce-8d7a-516b49b45d67@github.com>
Message-ID: <XMB2uyJSxzLDYmcYCxZ4_cGg3oS5gtRnksKaPr3GsBA=.8773b0cf-910b-4d29-b049-8ffea2cc4846@github.com>

On Fri, 25 Oct 2024 23:45:26 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I'm not sure what would be a useful message. All the `SecurityManager` check methods throw a `SecurityException` with no message. We had to specify something here because `AccessControlException` doesn't have a no-args ctor.
>
> I see. Maybe this is enough.

Actually, I changed the message to "checking permissions is not supported" which is the same as the exception message of`Permission.checkGuard` and `AccessController.checkPermission`.

https://github.com/openjdk/jdk/pull/21498/commits/b6fe405dbbe8ec19a18174bc48dd649feca3d6aa

>> You mean move the first sentence of the deprecated text to here?
>
> Oh, I just meant the class spec should have a body text. This is similar to my previous comment on the `Policy` class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819161320
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819162666

From mullan at openjdk.org  Mon Oct 28 14:26:45 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:45 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <5cNNcS3nKl9Xq1oRJl6UR0Hsa7TScT14a1vA0YsNcO4=.515dbc77-19b3-425d-88d3-5752f3916eca@github.com>

On Fri, 25 Oct 2024 21:02:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Policy.java line 90:
>> 
>>> 88:  *       and subject to removal in a future release. Consequently, this class
>>> 89:  *       is also deprecated and subject to removal. There is no replacement for
>>> 90:  *       the Security Manager or this class.
>> 
>> Don't you need at least one sentence as the body of the class spec here? Something like `Policy was...` which is similar to `AccessController`.
>
> Yes, we should be consistent. The deprecated text always comes first, and sometimes we want to say immediately why this class is not useful anymore in that text instead of later, further down. I don't know which is better. I guess I'll go with your suggestion just so it looks more like a normal class.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/09b6cd602c1f2c7998ed824878c5f5f43be69075

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819163498

From mullan at openjdk.org  Mon Oct 28 14:26:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:26:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <s11CKR8J4p4OO6MhnvG9htT8gCepixeepGrWXpTkb6o=.56e88ee6-6436-4d6e-8056-a9e23d2d66de@github.com>

On Thu, 24 Oct 2024 15:04:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1780:
> 
>> 1778:      * <p>
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
> 
> Suggestion:
> 
>      * {@code Font.decode(String)}.
> 
> Period is missing.

Not part of this change, can be fixed later as a follow-on cleanup.

> src/java.desktop/share/classes/java/beans/Expression.java line 1:
> 
>> 1: /*
> 
> Needs copyright year update.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java line 1:
> 
>> 1: /*
> 
> Copyright year needs updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

> test/jdk/java/beans/XMLEncoder/6777487/TestCheckedCollection.java line 1:
> 
>> 1: /*
> 
> Copyright years need updating.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/a7a4944630d63874a8d360cec798247eab144b42

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819152998
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819155061
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156309
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819156796

From kevinw at openjdk.org  Mon Oct 28 14:33:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 28 Oct 2024 14:33:27 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid
In-Reply-To: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
Message-ID: <pH3eC0Fcv5onerhUNIXokMyZ52VM1-cvPIEZdf4dGTQ=.dac5323a-1952-480d-99b6-cc1372027f4e@github.com>

On Thu, 24 Oct 2024 16:07:50 GMT, Larry Cable <duke at openjdk.org> wrote:

> the implementation I originally provided does not in fact solve the issue!
> 
> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
> 
> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
> 
> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
> 
> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
> 
> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
> 
> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
> 
> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
> 
> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
> 
> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
> 
> therefore an "attacher" has two choices when attempting to attach:
> 
> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>   - this works with both peers and descendants
> 
> - use /tmp
>   - this only works if the "attacher" and "attachee" share a /tmp in common
> 
> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
> 
> In these circumstances, the "attacher" can only resort to /tmp wh...

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 330:

> 328:     private static final long SIGQUIT = 1L << 2;
> 329: 
> 330:     private static boolean checkCatchesAndSendQuitTo(int pid, boolean throwIfNotReady) throws AttachNotSupportedException, IOException {

Looks like the throwIfNotReady param is not needed, can be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1819178799

From stooke at openjdk.org  Mon Oct 28 14:40:44 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 28 Oct 2024 14:40:44 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
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: <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@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](https://github.com/user-attachments/files/17517412/sample.txt)

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  changes from review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/c6628d30..7bbb03da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=00-01

  Stats: 88 lines in 1 file changed: 3 ins; 42 del; 43 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 Oct 28 14:40:44 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Mon, 28 Oct 2024 14:40:44 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <d3r0etEQmAznblWF456XYRySahieTf-PLhhnseP9y6o=.07d079b5-c40a-48fe-b76e-da3c7da495b5@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <d3r0etEQmAznblWF456XYRySahieTf-PLhhnseP9y6o=.07d079b5-c40a-48fe-b76e-da3c7da495b5@github.com>
Message-ID: <Axud-_Df1FQ_9Y5qrzVpBLTqOjOS1JhhTfk4CEWcePs=.1d356a81-f0f0-4c17-995a-3f918c372502@github.com>

On Fri, 25 Oct 2024 15:09:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes from review
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 120:
> 
>> 118: 
>> 119:   static const char* tagToStr(uint32_t user_tag) {
>> 120:     switch (user_tag) {
> 
> You could reduce the code and remove duplications with an [x macro](https://en.wikipedia.org/wiki/X_macro) if you wanted.

Doing this, I found a copy-paste error, so thanks for the suggestion!

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 360:
> 
>> 358:       break;
>> 359:     } else if (retval < (int)sizeof(region_info)) {
>> 360:       fatal("proc_pidinfo() returned %d", retval);
> 
> I would make this an assert, and return without printing anything in release.

I missed this.  I have changed it to the Windows version, where it prints the error and has an assert(), instead of fatal().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1819186695
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1819188325

From mullan at openjdk.org  Mon Oct 28 14:51:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
 <CXCyiQAUCYWjGZhpItE8g586xR2JberxRiBwOT5GCXQ=.3a21c72e-9b7f-4676-90d4-b3e413507d75@github.com>
Message-ID: <2jF7R61_yDPlFJ9Mh9c9RW-TDvtp4UPDj2OrU1--r4M=.9359f0c1-76e1-4287-8d53-05903baa6f25@github.com>

On Fri, 25 Oct 2024 23:58:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>>> The class spec still mentions "permissions which are retrieved by the system policy by default". Shall we remove it? 
>> 
>> Yes I think we can remove that text.
>> 
>>> Also, getPermissions always returns an empty Permissions object, do we need to add an @apiNote for it?
>> 
>> You mean a warning like we have in the `Permission` subclasses?
>> 
>> `URLClassLoader` and other subclasses still populate these permissions, but the plan is to revisit that code and potentially remove it later. I will remove "granted to" in the `@return` text.
>
> Sorry, I got it wrong. I thought this `return new Permissions()` is something new. In fact, it was there before this change.
> 
> On the other hand, I looked at its subclasses and their `getPermissions(CodeSource cs)` could return quite complicated permission collections. I assume it does not really matter since they are all useless now, right?

I removed the text "permissions which are retrieved by the system policy by default" from the class description and added an API note that permissions cannot be used to control access to resources. See https://github.com/openjdk/jdk/pull/21498/commits/8b527c90e434e63fd00a719aedda50d8d27e93b5

> On the other hand, I looked at its subclasses and their getPermissions(CodeSource cs) could return quite 
> complicated permission collections. I assume it does not really matter since they are all useless now, right?

Yes, although I would prefer to handle those as follow-on issues, I filed one for `URLClassLoader`: https://bugs.openjdk.org/browse/JDK-8343150

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819210679

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <ecXA9z7pXC8iHPzwyo5ZNBiptYS950MNZdm3yjHFd-Y=.f95ed696-c762-40f2-9079-e218b36f164b@github.com>

On Thu, 24 Oct 2024 15:57:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/beans/PropertyEditorManager.java line 71:
> 
>> 69:      *
>> 70:      * @param targetType   the class object of the type to be edited
>> 71:      * @param editorClass  the class object of the editor classs
> 
> Suggestion:
> 
>      * @param editorClass  the class object of the editor class
> 
> Typo with an extra ?s?. The line should remain unchanged.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

> src/java.desktop/share/classes/javax/swing/WindowConstants.java line 1:
> 
>> 1: /*
> 
> Needs updating the copyright year.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b78a7b6a2e5f96a98c81c68a8d9db3745e4efc3b

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819200392
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819172129

From mullan at openjdk.org  Mon Oct 28 14:51:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
 <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
Message-ID: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>

On Fri, 25 Oct 2024 23:20:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Right the JBS is about SM & SecurityException, but the test was repurposed to check if InvalidMidiDataException is thrown and to test this case for code coverage (when it was initially reviewed). 
>> I can update the test summary accordingly  -
>>  **"Check if MidiSystem.getSoundbank() throws InvalidMidiDataException when provided with invalid soundbank data"**
>> 
>> @azuev-java Your thoughts?
>
> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819186623

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <DiJnjPetyhNzLVZMXlT4R5dVCAmW5fOkqLYC28vmrRc=.a52eacdb-d380-4096-b739-74b3f479e6d9@github.com>
Message-ID: <IaFWniwJ0ayT2cKcMKQ3OSQfgSbE6Cdm_vACx8gYhNQ=.6ac87108-0c02-4e7f-a85c-b1c140e78512@github.com>

On Fri, 25 Oct 2024 20:31:40 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java line 1:
>> 
>>> 1: /*
>> 
>> I think we can delete this test. It verifies that popup menus are displayed in a windows `isAlwaysOnTop() == true` in stand-alone apps whereas for applets `isAlwaysOnTop() == false`.
>> 
>> If there's no such distinction, the test tests nothing but the fact that popup menus are displayed in always-on-top windows.
>> 
>> The updated test does not test anything for [JDK-6691503](https://bugs.openjdk.org/browse/JDK-6691503) and its changeset https://github.com/openjdk/jdk/commit/8dff6c648be296799e4a7e0e1964d339acc0d724.
>
> This test was initially deleted but then restored based on the following comment - https://github.com/openjdk/jdk/pull/21498#discussion_r1810297085
> 
> Since this test falls under similar category as test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java and based on your suggestion, I think we can delete it if it doesn't hold value after SM removal.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819190841

From mullan at openjdk.org  Mon Oct 28 14:51:50 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 14:51:50 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <LoVn9PpnjZ2E1RFGHbXhEb5UtLfJLi3OPApRQHkGKLo=.a91fa6cf-aaca-46a0-b5c4-0baf976b5a71@github.com>
 <2ZblO2qTzQaOiCMvDaGMmljsvvd6MeXheRKbpEkjQNU=.5d56714b-0e9b-48c8-a448-d561bd0ea992@github.com>
 <yQ_r-T9ojp-MBVESARYA03-H_GBr6VANfzvgQRQXbM0=.3d50f937-3b65-4d7f-9b1a-c004e43a25fb@github.com>
 <03UulfxEn8Ij1m7ACH4xF_wIUS7o-Gu57559o_3LDNQ=.14628317-cdaf-42a2-8aa5-f3930ed864f2@github.com>
Message-ID: <3UWYFypKVUDbFKF8O3Q1XuygK6WoWNs50jtx7yQooR4=.c7f4127d-2927-4750-8983-be5b7d163883@github.com>

On Fri, 25 Oct 2024 18:52:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @aivanov-jdk 
>> On macOS, popup is shifted up and does not cover the taskbar even without SM. 
>> 
>>> The updated test bug6694823.java works correctly on Windows and displays its popup over the Windows taskbar ? it is expected.
>>> Popup menus in stand-alone apps have their always-on-top flag set to true, therefore they can be displayed on top of the taskbar.
>> 
>> On native applications (eg. Word), popup menus don't overlap taskbar when clicked close to taskbar so do we consider this as expected behavior or the way it works currently (overlaps the taskbar)?
>
> The pop is shifted up on macOS because `LWCToolkit` returns `false` in `canPopupOverlapTaskBar`:
> 
> https://github.com/openjdk/jdk/blob/36d71735e3554264e8d17f7e0e72999ac639e398/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L900-L902
> 
> On Windows, apps can control the area where they want a popmenu display or exclude an area of the screen. At the same time, Firefox displays its right-click menu over the taskbar if the menu fits when dropped down. A native Win32 app with a menu bar displays popup menus over the taskbar if it fits on the screen; some menus could open upwards if their items don't fit on the screen to display downwards (I attached a screenshot to JBS). Popup menus in Win32 Notepad (the version in Windows 10) displays it's right-click menu over the taskbar if it fits.
> 
> At the same time, right-click menu of a window title never displays over the taskbar, the menu opens upward if it doesn't fit without covering part of the taskbar.
> 
> I'm pretty sure the default return value of `true` from `SunToolkit.canPopupOverlapTaskBar` isn't something that was chosen accidentally.
> 
> Windows applications may avoid showing popup over the taskbar (confining the popups inside the work area, see [`SystemParametersInfoW`](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfow) and `SPI_GETWORKAREA`). We can change the behaviour of the JDK.
> 
> Yet the failure of `bug6694823.java` without the security manager isn't a product bug in my opinion.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/aca9555a0b697bd9829224396a5448c88057009d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819180850

From mullan at openjdk.org  Mon Oct 28 15:09:54 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 15:09:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <di3QwjPshatki7F1k9zaiWfs8C5lgRBvLiYnMGXdmYE=.b95d7132-856f-4fbf-a7b1-818ed02d144d@github.com>

On Fri, 25 Oct 2024 20:59:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 125:
> 
>> 123:     }
>> 124: 
>> 125:     @Benchmark
> 
> Is this benchmark still useful if it is not comparing the SM vs the Non-SM case?

`ProtectionDomain` has not been deprecated and classes are still populated with PDs w/o an SM, so it may still have some value for measuring performance and detecting regressions/improvements.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819242889

From duke at openjdk.org  Mon Oct 28 15:49:22 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 15:49:22 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
Message-ID: <sGqI7JKrA0qpMUA6KJ1_LEWMYfHWBwmrXTmGOZWHBkA=.d9fddf2b-29b6-4831-8b63-9d55de955bd6@github.com>

On Fri, 25 Oct 2024 14:23:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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>
>
> src/hotspot/share/runtime/mutexLocker.cpp line 299:
> 
>> 297:   MUTEX_DEFN(ThreadsSMRDelete_lock           , PaddedMonitor, service-2); // Holds ConcurrentHashTableResize_lock
>> 298:   MUTEX_DEFN(ThreadIdTableCreate_lock        , PaddedMutex  , safepoint);
>> 299:   MUTEX_DEFN(SharedDecoder_lock              , PaddedMutex  , service-5);
> 
> Why this? Do we print stacks under NMT lock protection?

Yes I think so. `MemTracker::print_containing_region` first acquires the  NMT lock then the `SharedDecoder_lock` like this:

`MemTracker::print_containing_region` -->
`PrintRegionWalker::do_allocation_site` -->
`NativeCallStack::print_frame` --> 
`Decoder::get_source_info` --> 
`Decoder::shared_decoder_lock()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819307026

From duke at openjdk.org  Mon Oct 28 15:52:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 15:52:54 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <sGqI7JKrA0qpMUA6KJ1_LEWMYfHWBwmrXTmGOZWHBkA=.d9fddf2b-29b6-4831-8b63-9d55de955bd6@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
 <sGqI7JKrA0qpMUA6KJ1_LEWMYfHWBwmrXTmGOZWHBkA=.d9fddf2b-29b6-4831-8b63-9d55de955bd6@github.com>
Message-ID: <sIcUZ3xO0P7SZWr2Bq5Kol9id13rwAiCpiYklAy3kz4=.3473d4ea-e49f-4c09-8af9-28408aa3247b@github.com>

On Mon, 28 Oct 2024 15:45:31 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/mutexLocker.cpp line 299:
>> 
>>> 297:   MUTEX_DEFN(ThreadsSMRDelete_lock           , PaddedMonitor, service-2); // Holds ConcurrentHashTableResize_lock
>>> 298:   MUTEX_DEFN(ThreadIdTableCreate_lock        , PaddedMutex  , safepoint);
>>> 299:   MUTEX_DEFN(SharedDecoder_lock              , PaddedMutex  , service-5);
>> 
>> Why this? Do we print stacks under NMT lock protection?
>
> Yes I think so. `MemTracker::print_containing_region` first acquires the  NMT lock then the `SharedDecoder_lock` like this:
> 
> `MemTracker::print_containing_region` -->
> `PrintRegionWalker::do_allocation_site` -->
> `NativeCallStack::print_frame` --> 
> `Decoder::get_source_info` --> 
> `Decoder::shared_decoder_lock()`

Otherwise `make test TEST=hotspot_nmt` throws a lock rank error when running the test  `location_printing_mmap_1`. That test uses `MemTracker::print_containing_region`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819316109

From duke at openjdk.org  Mon Oct 28 16:12:39 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 16:12:39 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
Message-ID: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>

> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
> 
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1

Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:

 - add a comment explaining lock rank
 - remove unnecessary dropping of tracking level

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20852/files
  - new: https://git.openjdk.org/jdk/pull/20852/files/7ed996e2..976e26c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20852&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20852&range=07-08

  Stats: 10 lines in 3 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20852/head:pull/20852

PR: https://git.openjdk.org/jdk/pull/20852

From stuefe at openjdk.org  Mon Oct 28 16:12:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Oct 2024 16:12:39 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <wQLwmHusiFEGjJhgSzhJlbvQk3VY-Q7K9PLEH2LOWsA=.bf316b66-09bd-4e72-8817-363a07d21f5c@github.com>

On Mon, 28 Oct 2024 16:09:44 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

Good!

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20852#pullrequestreview-2399551819

From stuefe at openjdk.org  Mon Oct 28 16:12:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 28 Oct 2024 16:12:39 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <sIcUZ3xO0P7SZWr2Bq5Kol9id13rwAiCpiYklAy3kz4=.3473d4ea-e49f-4c09-8af9-28408aa3247b@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
 <sGqI7JKrA0qpMUA6KJ1_LEWMYfHWBwmrXTmGOZWHBkA=.d9fddf2b-29b6-4831-8b63-9d55de955bd6@github.com>
 <sIcUZ3xO0P7SZWr2Bq5Kol9id13rwAiCpiYklAy3kz4=.3473d4ea-e49f-4c09-8af9-28408aa3247b@github.com>
Message-ID: <E-ne_AonniSnwdjKj51D-HXcKmX3b13h_O_akFhBU6Y=.4f2aad0e-57e4-43b3-91de-0703029ddfd8@github.com>

On Mon, 28 Oct 2024 15:50:00 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Yes I think so. `MemTracker::print_containing_region` first acquires the  NMT lock then the `SharedDecoder_lock` like this:
>> 
>> `MemTracker::print_containing_region` -->
>> `PrintRegionWalker::do_allocation_site` -->
>> `NativeCallStack::print_frame` --> 
>> `Decoder::get_source_info` --> 
>> `Decoder::shared_decoder_lock()`
>
> Otherwise `make test TEST=hotspot_nmt` throws a lock rank error when running the test  `location_printing_mmap_1`. That test uses `MemTracker::print_containing_region`.

Thanks. But eew. Okay, ugly but not easy to fix.
Can you please add a trailing comment behind SharedDecoder lock that it needs to be lower than the NMT lock?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819338305

From duke at openjdk.org  Mon Oct 28 16:12:39 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 16:12:39 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <E-ne_AonniSnwdjKj51D-HXcKmX3b13h_O_akFhBU6Y=.4f2aad0e-57e4-43b3-91de-0703029ddfd8@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
 <sGqI7JKrA0qpMUA6KJ1_LEWMYfHWBwmrXTmGOZWHBkA=.d9fddf2b-29b6-4831-8b63-9d55de955bd6@github.com>
 <sIcUZ3xO0P7SZWr2Bq5Kol9id13rwAiCpiYklAy3kz4=.3473d4ea-e49f-4c09-8af9-28408aa3247b@github.com>
 <E-ne_AonniSnwdjKj51D-HXcKmX3b13h_O_akFhBU6Y=.4f2aad0e-57e4-43b3-91de-0703029ddfd8@github.com>
Message-ID: <EvhuSdUdkgsKZ-wRafUfYHz2rYp70tcCs-WusA2snH4=.7f6c92b1-7d65-4428-8ca6-768cb7bdb3aa@github.com>

On Mon, 28 Oct 2024 16:03:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Otherwise `make test TEST=hotspot_nmt` throws a lock rank error when running the test  `location_printing_mmap_1`. That test uses `MemTracker::print_containing_region`.
>
> Thanks. But eew. Okay, ugly but not easy to fix.
> Can you please add a trailing comment behind SharedDecoder lock that it needs to be lower than the NMT lock?

yes ok, I can add an explanatory comment there

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819342359

From duke at openjdk.org  Mon Oct 28 16:12:40 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 16:12:40 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v8]
In-Reply-To: <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <fHsHZp9L34NsvnF5CJGTVkQC8Xir75xT1OJQqH1Eb_A=.c63611e7-3cca-40cb-8648-0705622f1517@github.com>
 <KYtbmNiZg9n6bys4cnK6M25u8X9NpnZ4agAAi9BUWAo=.2a16a0f3-324d-4962-af92-a14a63f5b83b@github.com>
Message-ID: <leLnDEQWftXtcJBVQLEOlfOs0r49Bf_5DL0Ion09yOI=.51dcb48e-59e2-47c7-a85f-64a9c969fcd2@github.com>

On Fri, 25 Oct 2024 14:32:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> 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>
>
> src/hotspot/share/utilities/vmError.cpp line 724:
> 
>> 722:     MemTracker::reduce_tracking_to_summary();
>> 723:     // Manually unlock if already holding lock upon entering error reporting.
>> 724:     NmtVirtualMemory_lock->unlock();
> 
> Thinking this through some more, I am now unsure about my old advice. I think if we force-unlock the mutex here, there should be no need for dropping the tracking mode to summary. Sorry if I gave conflicting advice before.
> 
> So I think you could remove the reduce_tracking call (and its implementation).
> 
> Dropping to summary has the disadvantage that it makes the NMT report in the hs-err file look like user ran with summary more active, which may confuse analysts. Force-unlocking is the way to go.

Ok I see. I've removed the dropping of the tracking level and just kept the force unlocking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1819339376

From coleenp at openjdk.org  Mon Oct 28 16:27:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 16:27:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <L4tCHCM7YVRAbG1ApiIzIRZcKWuqiX821nIB9Grdls0=.8c8d62e3-4112-414d-9d5b-2a457bc367f5@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

Noticed while downloading this that some copyrights need updating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307

From coleenp at openjdk.org  Mon Oct 28 16:41:32 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 16:41:32 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
Message-ID: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>

On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
> 
>> 117:   return  mask.num_oops()
>> 118:         + 1 // for the mirror oop
>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
> 
> Where is this temp oop slot set and used?

It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819394224

From pchilanomate at openjdk.org  Mon Oct 28 17:24:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:24:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v13]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <dXalEie51SeOozW8Hjna9HrvB33PjXM_JxkPAcKAwOE=.89945004-4fa6-4420-baf4-e38ae1c6a9dd@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Simplify set last_sp in prepare_freeze_interpreted_top_frame
 - add authenticate_return_address() in StubAssembler::epilogue
 - Make member functions in ObjectWaiter const
 - Rename inflating_thread to locking_thread

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/66d5385f..7cb4cffd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=11-12

  Stats: 52 lines in 15 files changed: 1 ins; 3 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Mon Oct 28 17:35:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
Message-ID: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>

On Sat, 26 Oct 2024 00:17:33 GMT, Dean Long <dlong at openjdk.org> wrote:

>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>
Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:
> 
>> 189:   // must restore the rfp value saved on enter though.
>> 190:   if (use_pop) {
>> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));
> 
> leave() also calls authenticate_return_address(), which I assume we still want to call here.
> How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

Right. I added it here for now to follow the same style in all platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Suggestion:
> 
>   f.interpreter_frame_set_last_sp(f.unextended_sp());

Changed, here and in the other platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
> 
>> 157: 
>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
> 
> Suggestion:
> 
>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
> 
> Isn't that 2 words, not 3?

The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
I don't know why we do that for 64 bits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819473410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819465574
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086

From pchilanomate at openjdk.org  Mon Oct 28 17:35:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
 <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
Message-ID: <IIT6ZK5VHBwBQs0KkppCGOwgf55SIZk7-HKtZvFfIRQ=.d60d57ef-dd07-4a13-8909-969ad7a53d6b@github.com>

On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:
>> 
>>> 186:   // Avoid using a leave instruction when this frame may
>>> 187:   // have been frozen, since the current value of rfp
>>> 188:   // restored from the stub would be invalid. We still
>> 
>> It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>> Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
>>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>>
> Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
I think we need it for the pending exception case. I see we use rfp to get the exception pc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263

From pchilanomate at openjdk.org  Mon Oct 28 17:35:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
Message-ID: <RwO07ZXmUK-ZXOELiDyi595hIZZECD2720ZsYwLPGQE=.30718afc-d202-45ee-8ab3-9d9ae5e0959a@github.com>

On Fri, 25 Oct 2024 21:57:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/interpreter/oopMapCache.cpp line 268:
> 
>> 266:   }
>> 267: 
>> 268:   int num_oops() { return _num_oops; }
> 
> I can't find what uses this from OopMapCacheEntry.

It's needed for verification in VerifyStackChunkFrameClosure. It's called in OopMapCacheEntry::fill_for_native(), and we get there from here: https://github.com/openjdk/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp#L114

> src/hotspot/share/runtime/objectMonitor.hpp line 71:
> 
>> 69:   bool is_wait()           { return _is_wait; }
>> 70:   bool notified()          { return _notified; }
>> 71:   bool at_reenter()        { return _at_reenter; }
> 
> should these be const member functions?

Yes, changed to const.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958

From pchilanomate at openjdk.org  Mon Oct 28 17:35:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v13]
In-Reply-To: <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Or5Xd7PMUDemIZx4-6nAQm33zWNmHayXysbM4sSv2CE=.9cd08621-3a3a-4d33-b764-7521b4c86908@github.com>
Message-ID: <az8AjVGzJn_UTq7msHjpPM0jnyOISv5jEHsxcfKAUjI=.a74363e6-08d2-4364-b1ce-b274b82f23de@github.com>

On Fri, 25 Oct 2024 22:22:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Simplify set last_sp in prepare_freeze_interpreted_top_frame
>>  - add authenticate_return_address() in StubAssembler::epilogue
>>  - Make member functions in ObjectWaiter const
>>  - Rename inflating_thread to locking_thread
>
> src/hotspot/share/runtime/objectMonitor.hpp line 43:
> 
>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 43: // See next_waiter(), first_waiter(), etc.
> 
> Also a nice cleanup.  Did you reconcile the JVMTI code?

We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651

From pchilanomate at openjdk.org  Mon Oct 28 17:35:24 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <odXwYzPLvvXRkR8Ah1BNVk98f3oWOo_GgMxHNXSxlHE=.d8e15e55-f827-4f71-a1b5-9bbe449d2e61@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.6f2a0e80-136d-4717-8155-7501e7f5fe56@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.82387acd-27e3-4468-8184-625c68f2b7d6@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.0ed6ec3a-9b05-4288-a95c-71ad48ce542c@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.8bf238e3-389a-4c0e-a59e-a53b1a7461e2@github.com>
 <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.add45f48-9738-4eb3-a700-118f5bb56d4d@github.com>
Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.58bb9152-274c-4c43-9bca-2feae81bf4c6@github.com>

On Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.
>
> ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

Changed to locking_thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819461999

From pchilanomate at openjdk.org  Mon Oct 28 17:40:31 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 17:40:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <A6dy4k3d96Z-aRQxjQYUYtKdPlUfzxffzRKujbNaAZ4=.e4799b8f-347d-46b2-9005-045e049dcf44@github.com>
Message-ID: <V-i82-l9tdu_WL8c3eYDdX7LZxIpsl57b-90LWjeYyU=.3e835056-4a2d-4532-abb5-92b1d3ec79d2@github.com>

On Sat, 26 Oct 2024 00:30:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:
> 
>> 336:   // Make sure that extended_sp is kept relativized.
>> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
>> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()
> 
> Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

There are two cases where the interpreter native wrapper frame is freezed: synchronized native method, and `Object.wait()`. The extra push of the parameters to the stack is done after we synchronize on the method, so it only applies to `Object.wait()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705

From rsunderbabu at openjdk.org  Mon Oct 28 17:42:41 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Mon, 28 Oct 2024 17:42:41 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v4]
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <nkyGhLELRZXrVNDXba-8DPJwmhj-MzWYpZZGjOetTM8=.a52a1396-99b3-44cc-92d6-036085481cac@github.com>

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:

  Added javadoc for the new method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21641/files
  - new: https://git.openjdk.org/jdk/pull/21641/files/2d5ce321..17d73a62

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21641&range=02-03

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21641/head:pull/21641

PR: https://git.openjdk.org/jdk/pull/21641

From lmesnik at openjdk.org  Mon Oct 28 17:46:33 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 28 Oct 2024 17:46:33 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v4]
In-Reply-To: <nkyGhLELRZXrVNDXba-8DPJwmhj-MzWYpZZGjOetTM8=.a52a1396-99b3-44cc-92d6-036085481cac@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
 <nkyGhLELRZXrVNDXba-8DPJwmhj-MzWYpZZGjOetTM8=.a52a1396-99b3-44cc-92d6-036085481cac@github.com>
Message-ID: <guCDMqh3MR-gn0HZrQJ1ybxQ0Bz-IhUhO8A_RFWIC_w=.274d74dd-888d-404c-bba8-879eae579326@github.com>

On Mon, 28 Oct 2024 17:42:41 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
>> 
>> Testing done for
>> Tiers 1,2,3
>> test/hotspot/jtreg tests
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added javadoc for the new method

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21641#pullrequestreview-2399784712

From honkar at openjdk.org  Mon Oct 28 18:14:53 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:53 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
Message-ID: <UibYchrEh4IMGTL2M1YjvpMysipL1Clnov5XIuBs9zg=.d2006057-0749-4a3e-b194-3a3d512d0e5e@github.com>

On Fri, 25 Oct 2024 18:09:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> I've looked through the changes to `java.desktop` module and to tests under `java/awt`, `java/beans`, `javax/accessibility`, `javax/sound`, `javax/swing`, `com/sun/java/accessibility` (removed).

@aivanov-jdk Clientlibs review comments have been addressed and updated. Please re-review when you get a chance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442286841

From honkar at openjdk.org  Mon Oct 28 18:14:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 28 Oct 2024 18:14:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
Message-ID: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>

On Fri, 25 Oct 2024 22:52:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Can you please advice on ?Audit Core Reflection? category of tests. I'm not 100% sure if these tests need to be deleted or retained (May be some of them are required for code coverage purpose and/or testing code paths that are not covered by existing tests).
>
> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
> But I don't see a problem with keeping the rest of the test.

Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819521798

From bchristi at openjdk.org  Mon Oct 28 18:28:01 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:01 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <yPy9DNlPYRyWTHBE5WWerf-MwhvFPW0tXLeaEQ-ZB8s=.bf67126c-a0fd-436e-ac50-60ba35dd8923@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

java.prefs changes look good. (No prefs tests were changed.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2397377427

From bchristi at openjdk.org  Mon Oct 28 18:28:04 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 18:28:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
Message-ID: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>

On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>    by removing text that refers to granting permissions, but avoid changes that
>    affect the API specification, such as the description and format of input
>    parameters.
>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>    with adjusted text that avoids the word "permission".
>  - Add text to class description of MBeanServer stating that implementations
>    may throw SecurityException if authorization doesn't allow access to resource.
>  - Restore text about needing permissions from the desktop environment in the
>    getPixelColor and createScreenCapture methods.
>  - Add api note to getClassContext to use StackWalker instead and
>    add DROP_METHOD_INFO option to StackWalker.
>  - Change checkAccess() methods to be no-ops, rather than throwing
>    SecurityException.
>  - Merge
>  - Merge
>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09

src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:

> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link

Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1817954250

From ihse at openjdk.org  Mon Oct 28 18:28:37 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Oct 2024 18:28:37 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86
 Port
Message-ID: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>

This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).

This is the summary of JEP 479:
> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

-------------

Commit messages:
 - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339783
  Stats: 1551 lines in 53 files changed: 70 ins; 1417 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Mon Oct 28 18:28:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 28 Oct 2024 18:28:44 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

For this patch, I have removed the parts of the build that I knew of that were related to 32-bit Windows. Furthermore, I have searched for all defines across the code base that are related to 32-bit Windows, and removed the parts of the code that is no longer relevant. I have also made a cross-codebase search for terms like "win" and "32" and glanced through the results (that was a huge list) to see if I could spot anything that might need attention. 

There might of course still be special code that was developed to take care of Windows 32-bit that is no longer needed, but that is hard to find automatically. If anyone knows about some particular code, please let me know!

Most of the code was trivial to handle, but there are a few instances where I'd like some input from code owners. I've marked these with `FIXME` in the patch.

src/hotspot/cpu/x86/interpreterRT_x86_32.cpp line 47:

> 45: #ifdef AMD64
> 46: #ifdef _WIN64
> 47:    // FIXME: This is weird. How can we ever have _WIN64 for 32-bit code? I wonder what was meant. /ihse

I think this piece of code will never get compiled and should be removed, and just the `#else` clause kept, but I guess some code archaeology is in place to figure out how and why this was added in the first place.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1478:

> 1476:   int frame_complete = ((intptr_t)__ pc()) - start;
> 1477: 
> 1478:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

This file is now Linux only, so we should be able to remove any Windows special code. Someone with better knowledge about the product needs to confirm that the comment is indeed correct, and that this was only needed on Windows.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1714:

> 1712:   __ restore_cpu_control_state_after_jni(noreg);
> 1713: 
> 1714:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

Same here as above.

src/hotspot/cpu/x86/x86_32.ad line 3715:

> 3713: %}
> 3714: 
> 3715: // FIXME: The logic below do not apply anymore. Should we change anything? /ihse

Here too we don't need Windows-specific support, since this is Linux only. But I need confirmation that the comment is correct so this code is really just Windows-specific.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2442297077
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819532224
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819533829
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819533988
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819535092

From prr at openjdk.org  Mon Oct 28 18:44:19 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 28 Oct 2024 18:44:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <22AJ3u3UiSxFqANDpVqeJV3-H54pfkjt4YfbhbQ_T2Q=.8228b822-dd85-436d-a208-ff15995098eb@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The client/desktop related src and test changes have all now been reviewed by at least one client/desktop engineer.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399915245

From dlong at openjdk.org  Mon Oct 28 18:54:43 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 18:54:43 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>

On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
>> 
>>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>>> 1554:   adr(rscratch1, resume_pc);
>>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
>> 
>> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.
>
> Its indeed difficult to see how the value is propagaged. I think it goes like this:
> 
> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

Thanks, that's what I was missing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819586705

From pchilanomate at openjdk.org  Mon Oct 28 19:02:42 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:42 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v14]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <NKHa1oLTI0rADOD0YbcU2stZ315uyCkZnJyJ3LMp3rI=.7817f6e5-6abb-4c74-b1be-54dbdc42811e@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  extra suggestion to prepare_freeze_interpreted_top_frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/7cb4cffd..bd918fa7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=12-13

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Mon Oct 28 19:02:44 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:44 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
Message-ID: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>

On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long <dlong at openjdk.org> wrote:

> > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.
> 
> During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.
>
The problem is that freezing the frames can fail. By then we would have already added the ObjectWaiter as representing a virtual thread. Regarding efficiency (and ignoring the previous issue) both approaches would be equal anyways, since regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:
> 
>> 131: 
>> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 
> Suggestion:
> 
>   assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

Changed, here and in the other platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
Message-ID: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>

On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
>> 
>>> 308:     sp -= 2;
>>> 309:     sp[-2] = sp[0];
>>> 310:     sp[-1] = sp[1];
>> 
>> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?
>
> Could the problem be solved with a resume adapter instead, like the interpreter uses?

The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
Message-ID: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>

On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
It will just move the task of adjusting the size of the frame somewhere else.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819594475

From pchilanomate at openjdk.org  Mon Oct 28 19:02:45 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 19:02:45 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.045f7564-8bc7-4d87-b4db-f14db661c147@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.4e7804c9-eb95-4481-8080-a547951d0cb0@github.com>
Message-ID: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.46af32e2-e5db-4220-adae-d3bf80a76a8f@github.com>

On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Its indeed difficult to see how the value is propagaged. I think it goes like this:
>> 
>> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
>> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
>> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
>> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771
>
> Thanks, that's what I was missing.

Right, whatever address is in last_Java_pc is the one we are going to freeze for that frame, i.e. that's the address we are going to return to when resuming. For the freeze slow path this was already how it worked before this PR. For the fast path I added a case to correct the last pc that we freeze on preemption, as Richard pointed out in the last link, since otherwise we would freeze a different one. The idea is that if we already freeze the right pc, then on thaw we don't have to do anything. Note that when there are interpreter frames on the stack we always take the slow path.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819595482

From bchristi at openjdk.org  Mon Oct 28 19:05:46 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:05:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <MVzDG3v00pr-BbVREYbr2PXIfV-ChDESYKHwRqlWVTQ=.9fc15703-9e3a-439d-aa88-f8b06f71fac2@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 400:

> 398:      * AccessControlContext and contextClassLoader of new threads to
> 399:      * be the same as the thread invoking this
> 400:      * {@code privilegedThreadFactory} method.  A new

We no longer state that the contextClassLoader is set, though `PrivilegedThreadFactory` _does_ still set the ccl. Is this OK?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819601556

From dlong at openjdk.org  Mon Oct 28 19:07:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 19:07:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <mX7eC6LTaXVdUpxWrMLEujN8ZdYACUu6C4Ce6IRbIpo=.9ac355b2-bb47-480d-9211-d62a96e1521a@github.com>
 <LE4zyv5x324UMEqrbF0lDtkbIE1wBn7hP7iEyXQ3LDo=.2853ccba-a4d8-4343-a2d4-d948c2555ff8@github.com>
Message-ID: <MLUFZMaiWbNcdv_VRsyXdS0Xe7gKx4zK1YvVDXEiCUM=.f72c2828-d1d9-4ee3-afec-0156b7576f7a@github.com>

On Sat, 26 Oct 2024 06:56:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>> 
>>> 1565: 
>>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>>> 1567:   bind(resume_pc);
>> 
>> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?
>
> The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.
> 
> At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

OK, that makes sense now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366

From bchristi at openjdk.org  Mon Oct 28 19:19:52 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 19:19:52 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

src/java.base/share/classes/java/util/concurrent/Executors.java line 529:

> 527:      * execute the given {@code callable} under the current access
> 528:      * control context, with the current context class loader as the
> 529:      * context class loader. This method should normally be invoked

We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819618471

From shade at openjdk.org  Mon Oct 28 19:37:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 19:37:23 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Cursory review, sometimes with my 32-bit x86 maintainer hat on :)

make/autoconf/platform.m4 line 669:

> 667:   AC_ARG_ENABLE(deprecated-ports, [AS_HELP_STRING([--enable-deprecated-ports@<:@=yes/no@:>@],
> 668:       [Suppress the error when configuring for a deprecated port @<:@no@:>@])])
> 669:   if test "x$OPENJDK_TARGET_OS" = xwindows && test "x$OPENJDK_TARGET_CPU" = xx86; then

Can you just hollow `PLATFORM_CHECK_DEPRECATION` out, without removing? I think I am going to use it for full 32-bit port deprecation.

make/modules/jdk.accessibility/Launcher.gmk line 56:

> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
> 55:       NAME := jaccessinspector, \
> 56:       EXTRA_SRC := \

I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?

Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.

src/hotspot/os/windows/os_windows.cpp line 136:

> 134:   #define __CPU__ amd64
> 135: #else
> 136:   #define __CPU__ unknown

Should this be just `#error Unknown CPU`?

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:

> 521: 
> 522: extern "C" int SpinPause () {
> 523: #ifdef AMD64

Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2399951993
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819593526
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819596530
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819620086
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819631224

From shade at openjdk.org  Mon Oct 28 19:37:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Oct 2024 19:37:24 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <K5nrLP2pWkz0mqjiDKMZr6S4OCMUx1gJYIIfx7vaWw4=.d70758a7-bd77-4668-8cde-45202a0f3435@github.com>
Message-ID: <_3lAZxejWWmQabtHhqCrOePqNu5-fR07EuLvQuGHEDc=.7b429041-4b97-41f6-afb6-c60b477748c5@github.com>

On Mon, 28 Oct 2024 18:15:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/cpu/x86/interpreterRT_x86_32.cpp line 47:
> 
>> 45: #ifdef AMD64
>> 46: #ifdef _WIN64
>> 47:    // FIXME: This is weird. How can we ever have _WIN64 for 32-bit code? I wonder what was meant. /ihse
> 
> I think this piece of code will never get compiled and should be removed, and just the `#else` clause kept, but I guess some code archaeology is in place to figure out how and why this was added in the first place.

I think this is a copy-paste error from [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809): the code from `interpreterRT_x86_64.cpp` (where `WIN64` makes sense) was copy-pasted here in `interpreterRT_x86_32.cpp`. In fact, `AMD64` in  `interpreterRT_x86_64.cpp` makes no sense as well. I'll clean it up: [JDK-8343167](https://bugs.openjdk.org/browse/JDK-8343167).

> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1478:
> 
>> 1476:   int frame_complete = ((intptr_t)__ pc()) - start;
>> 1477: 
>> 1478:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> This file is now Linux only, so we should be able to remove any Windows special code. Someone with better knowledge about the product needs to confirm that the comment is indeed correct, and that this was only needed on Windows.

Nah, leave it as is. Let's not regress native stubs unnecessarily, and this whole file would be gone after we deprecate 32-bit port completely.

> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1714:
> 
>> 1712:   __ restore_cpu_control_state_after_jni(noreg);
>> 1713: 
>> 1714:   // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> Same here as above.

Same reply as above :)

> src/hotspot/cpu/x86/x86_32.ad line 3715:
> 
>> 3713: %}
>> 3714: 
>> 3715: // FIXME: The logic below do not apply anymore. Should we change anything? /ihse
> 
> Here too we don't need Windows-specific support, since this is Linux only. But I need confirmation that the comment is correct so this code is really just Windows-specific.

It looks like it is a dusty corner case. But the same logic as above applies: let's not touch it, and instead wait for it to go away with the remaining bits of 32-bit x86 port. I see `eRegP_no_EBP` is used for safepoint polls, so if we are wrong about the scope of this, rewriting these match rules to just `eRegP` might introduce surprising regressions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819606745
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819611536
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819612008
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819617067

From duke at openjdk.org  Mon Oct 28 19:43:48 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 28 Oct 2024 19:43:48 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <rlFEWbTcHq_QeQ0eMOxWT5ln5fTaZvh4IOnjfvgJNhM=.bf5b8d4a-0f52-45a5-8881-350b206cf95d@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

Thank you everyone for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2442466850

From duke at openjdk.org  Mon Oct 28 19:43:48 2024
From: duke at openjdk.org (duke)
Date: Mon, 28 Oct 2024 19:43:48 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <MDw2J04NGEQeJXMnk2zdKuTdGEfI75WH8g81YcDlx1w=.2519b3c8-c550-4933-8bd9-df55ca0d4848@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

@roberttoyonaga 
Your change (at version 976e26c1c5ca13439142d2b88c722d8e8eb4cba1) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2442467812

From dlong at openjdk.org  Mon Oct 28 19:49:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 19:49:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
Message-ID: <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>

On Sat, 26 Oct 2024 07:04:28 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
>> 
>>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>>> 3795:   __ testbool(rscratch1);
>>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
>> 
>> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?
>
> The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858

From dlong at openjdk.org  Mon Oct 28 20:12:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 20:12:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
Message-ID: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>

On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
>> 
>>> 117:   return  mask.num_oops()
>>> 118:         + 1 // for the mirror oop
>>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
>> 
>> Where is this temp oop slot set and used?
>
> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819687576

From rriggs at openjdk.org  Mon Oct 28 20:14:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 28 Oct 2024 20:14:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed all tests under test/jaxp/javax/xml/jaxp.
A few imports moved around unnecessarily but otherwise looks fine.

test/jaxp/javax/xml/jaxp/functional/org/w3c/dom/ptests/NodeTest.java line 53:

> 51: import org.w3c.dom.Node;
> 52: import org.w3c.dom.NodeList;
> 53: import static jaxp.library.JAXPTestUtilities.USER_DIR;

The import change was unnecessary.

test/jaxp/javax/xml/jaxp/unittest/sax/Bug7057778Test.java line 48:

> 46: import org.xml.sax.XMLReader;
> 47: import org.xml.sax.ext.DefaultHandler2;
> 48: import static jaxp.library.JAXPTestUtilities.USER_DIR;

Keep imports JAXPTestUtilities imports together.

test/jaxp/javax/xml/jaxp/unittest/stream/XMLEventReaderTest/EventReaderTest.java line 32:

> 30: import javax.xml.stream.XMLStreamException;
> 31: import javax.xml.stream.events.StartDocument;
> 32: import static org.testng.Assert.assertEquals;

Import change is unnecessary.

test/jaxp/javax/xml/jaxp/unittest/validation/Bug6925531Test.java line 52:

> 50:             + "        targetNamespace='jaxp13_test'\n"
> 51:             + "        elementFormDefault='qualified'>\n"
> 52:             + "    <element name='test' type='string'/>\n"

Would be a good use for multi-line strings.   """ """
But not worth changing.

test/jaxp/javax/xml/jaxp/unittest/xpath/XPathPrecedingTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

no change necessary

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2399985101
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819611468
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819667734
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819672433
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819646448
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819624631

From duke at openjdk.org  Mon Oct 28 20:27:27 2024
From: duke at openjdk.org (Larry Cable)
Date: Mon, 28 Oct 2024 20:27:27 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v2]
In-Reply-To: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
Message-ID: <eDf5F2pVFsjBTfFbBTqBcije9ELLo09mX92NuCP9w_Y=.d92b6c7a-0ef5-4d47-b768-e4874fbd6fc8@github.com>

> the implementation I originally provided does not in fact solve the issue!
> 
> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
> 
> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
> 
> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
> 
> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
> 
> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
> 
> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
> 
> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
> 
> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
> 
> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
> 
> therefore an "attacher" has two choices when attempting to attach:
> 
> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>   - this works with both peers and descendants
> 
> - use /tmp
>   - this only works if the "attacher" and "attachee" share a /tmp in common
> 
> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
> 
> In these circumstances, the "attacher" can only resort to /tmp wh...

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8342449: changed logic of attach loop to throw if target still not ready when timed out and consolidated comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21688/files
  - new: https://git.openjdk.org/jdk/pull/21688/files/9093333f..4bee5d1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=00-01

  Stats: 25 lines in 1 file changed: 8 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21688/head:pull/21688

PR: https://git.openjdk.org/jdk/pull/21688

From dlong at openjdk.org  Mon Oct 28 20:31:31 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 20:31:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <oyUPhCIJW6WWypzHd4h649wRv6Z69JJoBuQzpiqlep4=.4958e138-0621-4685-83b1-5e5a5d6516cc@github.com>
 <WYq6DOcik1uy_o4CzcaneWInLp2S1ELgtZP9pKzZXag=.82f54dce-df84-49f2-bc29-d6efc9c14540@github.com>
Message-ID: <ZiD3zPbaBP37iLtLrDy4bnb1cWW_M0jjnDzdbQt_ccE=.6fc41f86-2cfe-4701-ad89-4346e6853793@github.com>

On Mon, 28 Oct 2024 17:30:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
>> 
>>> 157: 
>>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
>> 
>> Suggestion:
>> 
>>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
>> 
>> Isn't that 2 words, not 3?
>
> The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
> I don't know why we do that for 64 bits.

OK, I think there are historical or technical reasons why it's hard to change, because of the way the JVM spec is written.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281

From aturbanov at openjdk.org  Mon Oct 28 20:57:26 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 28 Oct 2024 20:57:26 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
Message-ID: <2YN_DU3wh8tvIgq_GWrRNplVTrQi3lXs2fOe46MvHXU=.a299ddae-5e1f-4af1-a56d-ab10e3ff6925@github.com>

On Thu, 24 Oct 2024 03:01:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>  - disable test that fails with hotspot_runtime_non_cds_mode

test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/AOTClassLinkingVMOptions.java line 143:

> 141:     }
> 142: 
> 143:     static void init() throws Exception  {

Suggestion:

    static void init() throws Exception {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1819747252

From pchilanomate at openjdk.org  Mon Oct 28 20:58:33 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix vmStructs definitions
 - Remove generate_cont_resume_monitor_operation() + comment in ObjectSynchronizer::inflate_impl()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/bd918fa7..fc9aa074

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=13-14

  Stats: 5 lines in 4 files changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Mon Oct 28 20:58:33 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>

On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
> 
>> 2380:   __ bind(after_transition);
>> 2381: 
>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
> 
> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819744051

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.f4d6df35-1527-419f-84bd-ca197510a27e@github.com>
Message-ID: <Wz421HivVaSYw32P_FziXYHdelelv3igEJaecq1D0qM=.f4aa5a06-0330-4a13-8d1a-663aec849281@github.com>

On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:
> 
>> 600: 
>> 601:   address generate_cont_preempt_stub();
>> 602:   address generate_cont_resume_monitor_operation();
> 
> The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

Removed.

> src/hotspot/share/runtime/synchronizer.cpp line 1559:
> 
>> 1557:         // and set the stack locker field in the monitor.
>> 1558:         m->set_stack_locker(mark.locker());
>> 1559:         m->set_anonymous_owner();  // second
> 
> Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

No, I removed that comment. Both will be visible once we publish the monitor with `object->release_set_mark(markWord::encode(m))`. There was a "first" comment in method ObjectMonitor::set_owner_from_BasicLock() which I removed in [1]. Clearing _stack_locker now happens here in the `mark.has_monitor()` case. The order there doesn't matter either. If some other thread sees that the owner is anonymous and tries to check if he is the owner the comparison will always fail, regardless of reading the BasicLock* value or a nullptr value.

[1] https://github.com/pchilano/jdk/commit/13353fdd6ad3c509b82b1fb0b9a3d05284b592b7#diff-4707eeadeff2ce30c09c4ce8c5a987abf58ac06f7bf78e7717cffa9c36cc392fL195

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746524
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746309

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.25439e7f-9231-4650-b569-7ea187b21f8e@github.com>
Message-ID: <K5riEGYhTK3b9yrDmiB_hU9eUxZ5SstOxTPMSq0_VOw=.f58a72c2-ca12-428b-b05b-ebacb2123c12@github.com>

On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:
> 
>> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>> 328:                                                                                                                                      \
>> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> 
> to make the type assert more precise:
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 20b9609cdbf..f2b8a69c03f 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -326,7 +326,7 @@
>                                                                                                                                       \
>    nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>                                                                                                                                       \
> -  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> +  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
>    volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
>    volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
>    volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
> diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
> index 86d7277f88b..0492f28e15b 100644
> --- a/src/hotspot/share/runtime/vmStructs.cpp
> +++ b/src/hotspot/share/runtime/vmStructs.cpp
> @@ -786,8 +786,8 @@
>                                                                                                                                       \
>    volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
>    unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /*...

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746890

From pchilanomate at openjdk.org  Mon Oct 28 20:58:34 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 20:58:34 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <nqrLxs51X9EWsXA7WvBG83SJHMshmfnaaqrbemEQwcc=.a7b80b62-f5eb-415b-8128-edaac686daed@github.com>
 <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.fbfbe669-1b4b-431e-818f-df539c6fa846@github.com>
Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.d58b3e5a-0959-4cf1-a27c-59c2111012eb@github.com>

On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 202:
>> 
>>> 200: 
>>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>>> 202:   BasicLock* volatile _stack_locker;
>> 
>> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
>> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?
>
> `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

I remember I thought about doing this but discarded it. I don't think it will reduce complexity since we still need to handle that as a special case. In fact I removed several checks throughout the ObjectMonitor code where we had to check for this case. Now it works like with LM_LIGHTWEIGHT (also a plus), where once the owner gets into ObjectMonitor the owner will be already fixed. So setting and clearing _stack_locker is contained here in ObjectSynchronizer::inflate_impl(). Granted that we could do the same when restricting the ids, but then complexity would be the same. Also even though there are no guarantees about the ids I think it might look weird for somebody looking at a thread dump to only see odd ids.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819748043

From pchilanomate at openjdk.org  Mon Oct 28 21:04:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 21:04:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
Message-ID: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>

On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.
>
> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819757374

From mullan at openjdk.org  Mon Oct 28 21:07:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 28 Oct 2024 21:07:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:

> 1: /*

@wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:

> 1: /*

Missed a copyright update; will fix.

test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:

> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
> 29:  * @compile -XDignore.symbol.file Marshal.java
> 30:  * @run main/othervm/java.security.policy==test.policy Marshal

With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.

Also, missing a copyright update, will fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819757618
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819758300
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819756247

From dlong at openjdk.org  Mon Oct 28 21:10:19 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 21:10:19 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
Message-ID: <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>

On Fri, 25 Oct 2024 21:33:24 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore use of atPointA in test StopThreadTest.java
>  - remove interruptible check from conditional in Object::wait

src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:

> 144:   // Make sure that locals is already relativized.
> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)

What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504

From pchilanomate at openjdk.org  Mon Oct 28 21:16:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 21:16:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
 <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
Message-ID: <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>

On Mon, 28 Oct 2024 19:45:08 GMT, Dean Long <dlong at openjdk.org> wrote:

> If preemption was cancelled, we skip over the cleanup.
>
We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854

From bpb at openjdk.org  Mon Oct 28 21:33:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 28 Oct 2024 21:33:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <3zWmdX5pdYRfq9hBJGyY-lDdhgs9xuZ2xPLLKgpPYzU=.81747961-8d9b-4488-b31e-37d6a5bf4003@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

The `java/nio/file` src and test changes look all right.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2442669945

From bchristi at openjdk.org  Mon Oct 28 22:10:15 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 28 Oct 2024 22:10:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <HOiCwZKc-UJsz_0__Bzto-LuAGch7-AOdKyEs0xT_3Q=.248b7897-841e-4ad5-8f89-10a3e7cf8177@github.com>

On Fri, 25 Oct 2024 20:13:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/concurrent/Executors/PrivilegedCallables.java line 28:
> 
>> 26:  * @bug 6552961 6558429
>> 27:  * @summary Test privilegedCallable, privilegedCallableUsingCurrentClassLoader
>> 28:  * @run main PrivilegedCallables
> 
> There's nothing privileged here; the test should be renamed or deleted if it duplicates other non-privileged call tests.

`Executors.privilegedCallable()` and `Executors.privilegedCallableUsingCurrentClassLoader()` are still present in the `Executors` class (though deprecated for removal). This test should be removed when those methods are removed. In the meantime, the name of the test seems reasonable to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1819824791

From dlong at openjdk.org  Mon Oct 28 22:10:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 22:10:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <-QwQkd1q8h9GfvlRylpKl62-elBXg88W-zbgIzM9mQ8=.67b003d4-eae2-4681-99c5-36c0ff771dbb@github.com>
Message-ID: <ETmP3VrD8GXkLs_ttoK9aNgV3fODhmMzcRFzgwooApI=.0b1a54fb-88e4-441f-a2b2-49bfa6b5fcb3@github.com>

On Mon, 28 Oct 2024 20:58:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix vmStructs definitions
>  - Remove generate_cont_resume_monitor_operation() + comment in ObjectSynchronizer::inflate_impl()

Looking at this reminds me of a paper I read a long time ago, "Using continuations to implement thread management and communication in operating systems" (https://dl.acm.org/doi/10.1145/121133.121155).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996

From pchilanomate at openjdk.org  Mon Oct 28 22:10:54 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>

On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.
>
> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819831895

From pchilanomate at openjdk.org  Mon Oct 28 22:10:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
Message-ID: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>

On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.
>
> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:

|                ThreadA                |                   ThreadB             |           ThreadC             |
| --------------------------------------| --------------------------------------| ---------------------------------------------|
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
|                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
|                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
|                                       | ExitEpilog:releases monitorB          |                                              |
|                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
|                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
|                                       |                                       |     continues execution in Java              |
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
|                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
|  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
|  ExitEpilog:releases monitorA         |                                       |                                              |
|  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472

From pchilanomate at openjdk.org  Mon Oct 28 22:10:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 28 Oct 2024 22:10:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <7DdE1cEmYYE3HJc6iimDEhyi1BJnEhZjWWQ0BPNGzME=.9a6db567-5652-4ca7-b661-e30721e6962c@github.com>
Message-ID: <Y29qP6KBB5ziQIMQAKW8UDf4E0oolb63AtBAJtMrlPc=.d02c4f14-1d4f-45e0-9b75-8dbfd211e950@github.com>

On Mon, 28 Oct 2024 00:31:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It is, we still increment _waiters for the vthread case.
>
> Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

If the ObjectWaiter is associated with a vthread(we unmounted in `Object.wait`) we just return null. We'll skip it from JVMTI code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478

From coleenp at openjdk.org  Mon Oct 28 22:57:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.ce8b0118-04e7-4c3a-973b-d2ff0af2a109@github.com>
 <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.74b11788-e026-41e3-9bcf-7364f4bde843@github.com>
Message-ID: <Iauve4e-TfFi91-Hv_DrqLHSnKCNs5bspnsFy8b737w=.9f1bb78f-0f6d-49d9-862d-bf342756896b@github.com>

On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???
>
> Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

Yes the comment did seem to contradict the name of the function.  But it's something we can re-examine at some later time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819858784

From coleenp at openjdk.org  Mon Oct 28 22:57:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
Message-ID: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>

On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?
>
> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819869538

From dlong at openjdk.org  Mon Oct 28 22:57:14 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 22:57:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <38SJoqCEEOXwleDfJSdtcU_b79SWfiG6jjtpSz9pG10=.3896a4e0-18bb-4127-a774-6b8e8d1bc1c5@github.com>
 <M0XpizwbuzyKhqmxAZbjUkokmpy7KrJ0fXUY-M-dx4g=.7ca33d99-c73e-4d7a-a4b8-d9148f44ebd1@github.com>
 <IicDsC4WOipFu_MkxgNCWVtCir-ctmskGdsUozV0qlw=.0bcb2ada-a1f1-4bea-a8b6-62b2b22ec171@github.com>
 <NbrAkpX-1Efb4M1nOxBmA0Xwz_vkQjX8mY-jep20FB4=.6a0e975c-bcf9-4a9c-b703-cc12521ebf76@github.com>
Message-ID: <kIzpbt39CsWh1gBz35CCjVl8f7vkM_2dZp84RE0OC_U=.2571c54c-2bbf-47c5-aa87-c317d0fd6cb7@github.com>

On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.
>
>> If preemption was cancelled, we skip over the cleanup.
>>
> We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

OK got it.  I guess it's too early to know if it's worth it to further optimize this case, which is hopefully rare.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819865539

From coleenp at openjdk.org  Mon Oct 28 22:57:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 28 Oct 2024 22:57:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v15]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.f19ed659-0b21-4fef-953c-cb87d007709c@github.com>

On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
>> 
>>> 1273: 
>>> 1274:   if (caller.is_interpreted_frame()) {
>>> 1275:     _total_align_size += frame::align_wiggle;
>> 
>> Please put a comment here about frame align-wiggle.
>
> I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

ok that's helpful.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1552:
>> 
>>> 1550:   assert(!cont.is_empty(), "");
>>> 1551:   // This is done for the sake of the enterSpecial frame
>>> 1552:   StackWatermarkSet::after_unwind(thread);
>> 
>> Is there a new place for this StackWatermark code?
>
> I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

Okay, good!

>> src/hotspot/share/runtime/objectMonitor.hpp line 43:
>> 
>>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>>> 43: // See next_waiter(), first_waiter(), etc.
>> 
>> Also a nice cleanup.  Did you reconcile the JVMTI code?
>
> We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

Ok, good that there isn't a jvmti special case here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860241
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860643
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819864520

From dlong at openjdk.org  Mon Oct 28 23:13:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:13:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
Message-ID: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>

On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>> 
>>> 2380:   __ bind(after_transition);
>>> 2381: 
>>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>> 
>> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?
>
> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.

I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819880228

From erikj at openjdk.org  Mon Oct 28 23:21:06 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Oct 2024 23:21:06 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

I looked at the build system parts.

make/modules/jdk.accessibility/Lib.gmk line 34:

> 32: 
> 33:   ##############################################################################
> 34:   ## Build libjavaaccessbridge

Is double `##` intentional?

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2400419486
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819883994

From dlong at openjdk.org  Mon Oct 28 23:24:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:24:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
Message-ID: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>

On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.
>
> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819887000

From erikj at openjdk.org  Mon Oct 28 23:21:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 28 Oct 2024 23:21:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>

On Mon, 28 Oct 2024 18:58:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> make/modules/jdk.accessibility/Launcher.gmk line 56:
> 
>> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>> 55:       NAME := jaccessinspector, \
>> 56:       EXTRA_SRC := \
> 
> I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?
> 
> Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.

I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1819883595

From amenkov at openjdk.org  Mon Oct 28 23:32:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 28 Oct 2024 23:32:08 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v14]
In-Reply-To: <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>
Message-ID: <nsuQfFPkgjE5fOp8ZezOmOIp3rr9OVVMgSgXeF--_q8=.579a99f2-d805-434b-b30e-01b60d3330fd@github.com>

On Sun, 27 Oct 2024 21:45:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove newly added trailing space

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2400431422

From dlong at openjdk.org  Mon Oct 28 23:41:21 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:41:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
Message-ID: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>

On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.
>
>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>
> It will just move the task of adjusting the size of the frame somewhere else.

> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.

If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819896849

From dlong at openjdk.org  Mon Oct 28 23:49:25 2024
From: dlong at openjdk.org (Dean Long)
Date: Mon, 28 Oct 2024 23:49:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>

On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption?  It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards?  We aren't doing the monitor check atomically, so the monitor could get released right after we check it.  So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740

From pchilanomate at openjdk.org  Tue Oct 29 00:04:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment in VThreadWaitReenter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/fc9aa074..056d21ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=14-15

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 29 00:04:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
Message-ID: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>

On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.
>
> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>
The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Thread reference. But for synchronized native methods there could be more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819908946

From pchilanomate at openjdk.org  Tue Oct 29 00:04:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <m6SVOuANGtdAXPcB631jivyitpUJzqaisPF6PkAYIXI=.0c9ad7de-27d7-4c8a-a4c8-507ca83efe1a@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.2970b04d-572f-4d10-b930-d9893f5f3cea@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.c5efa9a1-9b03-4505-b2b9-0a9793b4418d@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.8cef08e3-f91e-4bb4-b9ec-990e1f9fcf85@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.0270e2b6-c84d-4989-83a5-c573fb8f9e22@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.64e08614-93e2-4990-8d11-7c587f7b3b3c@github.com>
 <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.53128026-245c-40ad-9534-17845a10e8ea@github.com>
Message-ID: <KN4s68yO3KTnPYb3y0eMexToy1B3J9bOQPwDhbuDpk0=.7f3b8544-c22b-49ca-85c9-99dc99727c3a@github.com>

On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.
>
>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>>
> The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Thread reference. But for synchronized native methods there could be more.

> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change.
>
Because before this PR we never freezed interpreter frames belonging to native methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819909304

From pchilanomate at openjdk.org  Tue Oct 29 00:04:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 00:04:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.9eefa0d9-e682-4700-b647-e483eb39d3bf@github.com>
Message-ID: <Z-POFV3noL0adSkJwHIfc-RbkfBedii0V1qRp-WQ6Ws=.8fd850d2-de01-47bf-a44b-56c9bf5bf68a@github.com>

On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.
>
> The first sentence is not a sentence. Is it supposed to be saying:
> 
> // The first time we run after being preempted on Object.wait()
> // we check if we were interrupted or the wait timed-out ...
> 
> ?

Yes, I fixed the wording.

>> Only when facing contention on this call. But once we have the monitor we don't.
>
> But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

We will have the native wrapper frame at the top, but we still need to add some extra check to differentiate this `jni_enter()` case with respect to the case of facing contention on a synchronize native method, where we do allow to unmount (only when coming from the interpreter since the changes to support it where minimal). I used the NoPreemptMark here, but we could filter this case anywhere along the freeze path. Another option could be to check `thread->current_pending_monitor_is_from_java()` in the ObjectMonitor code before trying to preempt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921

From jlu at openjdk.org  Tue Oct 29 00:19:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Oct 2024 00:19:29 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
Message-ID: <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>

> A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 
> 
> 
> 
>>     ExceptionCheck
>>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
>> 
>>     jboolean ExceptionCheck(JNIEnv *env);
>> 
>>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  address other cases in Hotspot

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21724/files
  - new: https://git.openjdk.org/jdk/pull/21724/files/6dd00003..c3ecb692

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21724&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21724&range=00-01

  Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21724.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21724/head:pull/21724

PR: https://git.openjdk.org/jdk/pull/21724

From jlu at openjdk.org  Tue Oct 29 00:19:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 29 Oct 2024 00:19:30 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <bp0k-FpfayXSHao6bRxJjZs1hmeNh4_lkt_XR5JVNY0=.4f1e3054-8065-4cc9-939f-d2ebb92004e4@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
 <bp0k-FpfayXSHao6bRxJjZs1hmeNh4_lkt_XR5JVNY0=.4f1e3054-8065-4cc9-939f-d2ebb92004e4@github.com>
Message-ID: <QKHe97lNJ3IZ5hN-stoyFrggHggV5tY5x2DhEqOiz1Q=.1f081fe0-c5da-441f-bab1-838c2a7002b9@github.com>

On Mon, 28 Oct 2024 03:12:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address other cases in Hotspot
>
> @justin-curtis-lu  you have missed a large number of usages:
> 
> ./share/prims/nativeEntryPoint.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/prims/methodHandles.cpp:    guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/prims/upcallLinker.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/prims/unsafe.cpp:  if (env->ExceptionOccurred()) {
> ./share/prims/upcallStubs.cpp:  guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> ./share/runtime/continuation.cpp:    guarantee(!env->ExceptionOccurred(), "register jdk.internal.vm.Continuation natives");
> 
> 
> Thanks

Thanks for taking a look and catching those other occurrences @dholmes-ora. Addressed in https://github.com/openjdk/jdk/pull/21724/commits/c3ecb692c8fba1ce164169340a7d97785699e58f.
(Updated the JBS subtask issue as well to include those cases)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21724#issuecomment-2442911022

From sspitsyn at openjdk.org  Tue Oct 29 01:39:16 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 01:39:16 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v11]
In-Reply-To: <oIA2BbAM67QClHaoADOTGTMK4_2jqaQIkT4YEx-abik=.d10d38d9-6f6b-4190-8a79-984909a07533@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <t10ajKUS39rKRZsnkxRkQewy-XfRGoFkqgSNiXvG_k4=.825fe6b6-c16d-49d3-857f-30dac762f2e5@github.com>
 <aZhg_op6XpuDqW9ToM_CcQgZLrZKb_aoY5OpttkkOlQ=.ce0df356-b718-40c3-ab1d-7b5115296746@github.com>
 <UpiAUMlQ0zi4vlhOxKPgECTn-Z0bFBSJyCMi46bz07M=.3bd77cb4-6cf1-4995-affc-e359e9d7d35d@github.com>
 <oIA2BbAM67QClHaoADOTGTMK4_2jqaQIkT4YEx-abik=.d10d38d9-6f6b-4190-8a79-984909a07533@github.com>
Message-ID: <Iw_khC9qcHdaOwRnNjgExaLhURAzlq1_LkSVHULcuoY=.e07fa9e9-82ef-42a2-a595-945afda55ecc@github.com>

On Sat, 26 Oct 2024 06:40:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Good catch, thanks.
>> These two functions are impacted by temporary VTMS transitions. It seems we fail to hide frames in these transitions while we skip the JVMTI events in their context. I'll try to fix this issue.
>
> I'd suggest to file a separate bug on this issue as it has to be tested well.
> Please, let me know if you are okay with it.
> I've added an assert to catch a temporary VTMS transition in a context where we skip frames but do not see it fired yet. Not sure, why.

Alan has a plan and fix to get rid of temporary transitions from the `VirtualThread` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1819961511

From dlong at openjdk.org  Tue Oct 29 01:45:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 01:45:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:

> 75:     // Interpreter frames
> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only

This conflicts with sender_sp_offset.  Doesn't that cause a problem?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369

From sspitsyn at openjdk.org  Tue Oct 29 01:46:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 01:46:51 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v15]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <V6ky6GzX3j3Fqqb_Ri5Y4xcImGTxegQb6A_0xpxUg2M=.583b6ec0-fc49-4a7d-8cb4-4121bd9418e1@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: tweak description of the annotation class JvmtiHideEvents

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/22e8ab7d..826adc7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=13-14

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Tue Oct 29 01:46:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 01:46:51 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v14]
In-Reply-To: <uMmIXw5kTZKG3gn4mJXdreadf7Ys2FXFHfyVR1wacSQ=.f737b830-b339-493a-9246-1c445e8b6464@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <spuQYeGwvkk3KT6VTO55OZRiOIYhK5A7t8KAp98_wjg=.8b00d11f-cfaa-4430-999d-fc1c056e0111@github.com>
 <uMmIXw5kTZKG3gn4mJXdreadf7Ys2FXFHfyVR1wacSQ=.f737b830-b339-493a-9246-1c445e8b6464@github.com>
Message-ID: <O_H2t_qfTb-FxMH_TEeeyFZKA98k9KBXY56vJVMrcGo=.1c729e1f-0441-45e1-a459-bd1b68442b2c@github.com>

On Mon, 28 Oct 2024 05:56:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove newly added trailing space
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 32:
> 
>> 30: /**
>> 31:  * A method may be annotated with JvmtiHideEvents to hint it is not
>> 32:  * desirable to sent JVMTI events in context of the annotated method.
> 
> s/sent/send/ 
> 
> Also might be cleaerr to drop "not desirable" from the sentence as it begs too many questions.

Thanks, fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1819964271

From sspitsyn at openjdk.org  Tue Oct 29 01:46:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 01:46:54 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v8]
In-Reply-To: <ak89_CLmtt00JS8ZiVpHDo8cAihMalDuWRZvTuu1YLQ=.0ef6c740-02ef-4659-8d52-b762961d6b18@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <15ZEmA1D4X71LAEk66t2yPYmkdYvOI5W1ySny1-k9TI=.14eb1bd0-d75a-4a93-899c-a563a53bb058@github.com>
 <ak89_CLmtt00JS8ZiVpHDo8cAihMalDuWRZvTuu1YLQ=.0ef6c740-02ef-4659-8d52-b762961d6b18@github.com>
Message-ID: <10WQdk4k1lqdYulpHPUG9dalzsolu52iFpk3Z9RAc-s=.5783b158-88c4-47a4-b2de-7df23d7e0041@github.com>

On Wed, 23 Oct 2024 07:24:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge
>>  - review: explain better what methods can be annotated with JvmtiMountTransition
>>  - review: clarify the use of annotation @JvmtiMountTransition in yield/yield0
>>  - review: moved notifyJvmtiStart/notifyJvmtiEnd calls from VirtualThread.run to the caller
>>  - review: tweaked disabler for carrier threads; more hiddenjvmti_mount_transition frames
>>  - Disallow NotifyFramePop for enter/enter0/VirtualThread.run/VThreadContinuation.run
>>  - review: 1. Minor tweaks in new test; 2. Refactor skip_hidden_frames in two
>>  - fix one more place with trailing spaces
>>  - fix trailing spaces
>>  - add new test coverage with  vthread/CheckHiddenFrames
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d6eddcda...54dc2b4a
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiMountTransition.java line 32:
> 
>> 30: /**
>> 31:  * A method may be annotated as "jvmti mount transition" to hint
>> 32:  * it is desirable to omit it from JVMTI stack traces.
> 
> Might be better to replace both usages of "jvmti mount transition" with JvmtiMountTransition.
> 
> "virtual thread mount state transition (VTMS transition)" should probably be "Virtual Thread Mount State (VTMS) transition".
> 
> The updated wording is better but I think this still hard to audit to know if you've got the usages in the right place. Maybe we can re-visit it in the future.

I believe it has been fixed with the latest updates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1819965016

From dlong at openjdk.org  Tue Oct 29 02:02:26 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:02:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:

> 1349:   // set result handler
> 1350:   __ mov(result_handler, r0);
> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));

I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901

From dlong at openjdk.org  Tue Oct 29 02:12:25 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:12:25 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <qLIzGUcEFWFMi2Uckt0Yqnm8n85Vdjv8UWB-lti0m7o=.2a3d5139-a711-4dc9-a256-f2725be5fc2e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223:

> 221: }
> 222: 
> 223: void StubAssembler::epilogue(bool use_pop) {

Is there a better name we could use, like `trust_fp` or `after_resume`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640

From dlong at openjdk.org  Tue Oct 29 02:19:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:19:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <kAwXuYSJJfq0SijYJU_Ktw9tMf7lW1FRmXS581ZRmV8=.f836e40d-ec26-4b81-ad86-4e455bcd5727@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:

> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
> 642: #ifdef _LP64
> 643:   return r15_off / 2;

r15_off is a byte offset, so this returns a 16-bit short offset?  I think we need a comment here to explain the / 2 and what this returns.

src/hotspot/cpu/x86/frame_x86.cpp line 431:

> 429:   if (cb == Runtime1::blob_for(C1StubId::monitorenter_id) ||
> 430:       cb == Runtime1::blob_for(C1StubId::monitorenter_nofpu_id)) {
> 431:     thread_addr = (JavaThread**)(f.sp() + Runtime1::runtime_blob_current_thread_offset(f));

So this expects an offset in intptr_t units from runtime_blob_current_thread_offset(), but I thought it took a byte offset and then divided by 2.  I'm confused.

src/hotspot/share/c1/c1_Runtime1.hpp line 138:

> 136:   static void initialize_pd();
> 137: 
> 138:   static uint runtime_blob_current_thread_offset(frame f);

I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819983752
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522

From dlong at openjdk.org  Tue Oct 29 02:39:20 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:39:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <STXbA_YPsg6BunymS3r47wgamIcV5b_Zi-Bq8bFh_x4=.ff45571e-6c8c-45e7-ad8c-5eef3583d09e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:

> 357:   push_cont_fastpath();
> 358: 
> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.

>From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648

From dlong at openjdk.org  Tue Oct 29 02:49:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 02:49:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <TTF1D8Vo9G4KO-rN0Ut1vKIVFHvae1KBzR-5csVw73w=.cbdef9cc-4111-460e-9261-5e68d63475ad@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:

> 1507:     Label no_oop;
> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));

We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377

From duke at openjdk.org  Tue Oct 29 03:15:07 2024
From: duke at openjdk.org (duke)
Date: Tue, 29 Oct 2024 03:15:07 GMT
Subject: RFR: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler [v4]
In-Reply-To: <nkyGhLELRZXrVNDXba-8DPJwmhj-MzWYpZZGjOetTM8=.a52a1396-99b3-44cc-92d6-036085481cac@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
 <nkyGhLELRZXrVNDXba-8DPJwmhj-MzWYpZZGjOetTM8=.a52a1396-99b3-44cc-92d6-036085481cac@github.com>
Message-ID: <ashQ-gUPUkHRngM6FMLwcxJqhcDdskyzFMLvVYSk1lQ=.4348bcd3-e8ab-4e80-ac09-3e2d9eee226d@github.com>

On Mon, 28 Oct 2024 17:42:41 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

>> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
>> 
>> Testing done for
>> Tiers 1,2,3
>> test/hotspot/jtreg tests
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added javadoc for the new method

@rsunderbabu 
Your change (at version 17d73a6253477684faf4b3d03084953d1256b088) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21641#issuecomment-2443110464

From cjplummer at openjdk.org  Tue Oct 29 04:19:05 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 29 Oct 2024 04:19:05 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
Message-ID: <OlpiRkIsVlANkkh7G9ToTnblgnBqTL_IGWBiC9w902I=.909dd972-afef-4746-abbf-ae7817ad9d7d@github.com>

On Fri, 25 Oct 2024 22:44:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix enables logging in the test agent to get more details about intermittent failures.

Serguei explained in the parent bug why it is failing, so I'm not sure why you need the verbose output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21725#issuecomment-2443168258

From sspitsyn at openjdk.org  Tue Oct 29 04:43:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 04:43:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:

> 1080:     } else {
> 1081:       assert(vthread != nullptr, "no vthread oop");
> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);

Nit: The name `oopCont` does not match the HotSpot naming convention.
       What about `cont_oop` or even better just `cont` as at the line 2550?

src/hotspot/share/prims/jvmtiExport.cpp line 1682:

> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));

I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

src/hotspot/share/prims/jvmtiExport.cpp line 2879:

> 2877:   JvmtiVTMSTransitionDisabler::start_VTMS_transition((jthread)vthread.raw_value(), /* is_mount */ true);
> 2878:   current->rebind_to_jvmti_thread_state_of(current->threadObj());
> 2879: }

This function looks a little bit unusual. I understand it is called
I need to think about the consequences but do not see anything bad so far.
I'll look at the `ObjectMonitor` and `continuation` side updates to get more details on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820012783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820052049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820062505

From cjplummer at openjdk.org  Tue Oct 29 04:48:07 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 29 Oct 2024 04:48:07 GMT
Subject: RFR: 8342577: Clean up JVMTI breakpoint support
In-Reply-To: <JbSsksMFRTSKodRSJKPZVM99HM84BeAzpK4LqKFWPmY=.f276d4f4-a79c-40db-a86a-20cd6722ca86@github.com>
References: <JbSsksMFRTSKodRSJKPZVM99HM84BeAzpK4LqKFWPmY=.f276d4f4-a79c-40db-a86a-20cd6722ca86@github.com>
Message-ID: <Sq9cCqoc-SYEgRv1f6UXj1_3JE-BeHc5XR2JXKzi48A=.0b3917ad-6d1d-43f9-b3cb-26174df24705@github.com>

On Thu, 24 Oct 2024 01:42:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix cleans up code to support list of JVMTI breakpoints.
> - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped;
> - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code;
> - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637);
> - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor;
> - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass;
> 
> Testing: tier1..tier6

Overall looks good. I just made a testing comment and a general comment about the optimization you did, but no need for changes.

src/hotspot/share/prims/jvmtiImpl.cpp line 208:

> 206: 
> 207: JvmtiBreakpoints::JvmtiBreakpoints()
> 208:     : _elements(5, mtServiceability) {

Do we have tests that create more than 5 breakpoints? I just want to make sure the array growing code is exercised. You could stress it by testing with the initial size set to 1.

src/hotspot/share/prims/jvmtiImpl.cpp line 276:

> 274:     if (bp.method()->method_holder() == klass) {
> 275:       bp.clear();
> 276:       remove(i);

After reading the original comments, I get the feeling that the concern was that the array might be re-organized (recached). The comment "...the next entry might no longer be at i+1" of course is true. It would be at i if there was no recaching, in which case you could use while loop starting at 0 and not increment `i` if the entry is deleted.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21675#pullrequestreview-2400686253
PR Review Comment: https://git.openjdk.org/jdk/pull/21675#discussion_r1820068812
PR Review Comment: https://git.openjdk.org/jdk/pull/21675#discussion_r1820079694

From alanb at openjdk.org  Tue Oct 29 06:26:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 06:26:36 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation
Message-ID: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>

This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.

The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:

1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.

- jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.

The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/21735/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343132
  Stats: 354 lines in 16 files changed: 91 ins; 170 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/21735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21735/head:pull/21735

PR: https://git.openjdk.org/jdk/pull/21735

From alanb at openjdk.org  Tue Oct 29 06:36:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 06:36:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
Message-ID: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>

On Mon, 28 Oct 2024 19:16:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
> 
>> 527:      * execute the given {@code callable} under the current access
>> 528:      * control context, with the current context class loader as the
>> 529:      * context class loader. This method should normally be invoked
> 
> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?

That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820163200

From alanb at openjdk.org  Tue Oct 29 06:48:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 06:48:08 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v15]
In-Reply-To: <V6ky6GzX3j3Fqqb_Ri5Y4xcImGTxegQb6A_0xpxUg2M=.583b6ec0-fc49-4a7d-8cb4-4121bd9418e1@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <V6ky6GzX3j3Fqqb_Ri5Y4xcImGTxegQb6A_0xpxUg2M=.583b6ec0-fc49-4a7d-8cb4-4121bd9418e1@github.com>
Message-ID: <QuxVo6cfFZ0Ip274SSCVGhBoRSaPhQONLaFv1sxU77U=.7a62f7da-79d0-48b6-a6e4-4f2599c2e224@github.com>

On Tue, 29 Oct 2024 01:46:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: tweak description of the annotation class JvmtiHideEvents

src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 32:

> 30: /**
> 31:  * A method may be annotated with JvmtiHideEvents to hint the JVMTI events
> 32:  * should not be generated in context of the annotated method.

The sentence isn't quite right. I think you want to say that it's "a hint that JVMTI events" or "to hint that JVMTI events".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1820174554

From jwaters at openjdk.org  Tue Oct 29 07:02:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 07:02:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:

> 26: #include "runtime/sharedRuntime.hpp"
> 27: 
> 28: #ifdef _WIN64

Just a heads up: Due to a bug, this entire file is never used at all

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820188590

From duke at openjdk.org  Tue Oct 29 07:53:16 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 29 Oct 2024 07:53:16 GMT
Subject: Integrated: 8304824: NMT should not use ThreadCritical
In-Reply-To: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
Message-ID: <n1ZrnxyI_M4H3biWqzjccFsD5Cfl_N5OuZbWXsuMBvM=.fe99558c-ded9-40f9-ba54-96c75d2d5189@github.com>

On Wed, 4 Sep 2024 14:17:08 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary
> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
> 
> Testing:
> - hotspot_nmt
> - gtest:VirtualSpace
> - tier1

This pull request has now been integrated.

Changeset: 0abfa3ba
Author:    Robert Toyonaga <rtoyonag at redhat.com>
URL:       https://git.openjdk.org/jdk/commit/0abfa3ba8f72538f62be838c1ebac8cfbdd14cdf
Stats:     62 lines in 15 files changed: 19 ins; 21 del; 22 mod

8304824: NMT should not use ThreadCritical

Reviewed-by: stuefe, dholmes, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/20852

From stuefe at openjdk.org  Tue Oct 29 08:04:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 29 Oct 2024 08:04:09 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
References: <Pq9MywPCfQoBzJejNv7uanhIhUla-PKuRNcbHe_Yx78=.b9ea83a8-7a35-4a28-aabd-9cc5ce8667f1@github.com>
 <q3HWnGAgc0qg6SxSA219UjSBqRxGZpaxjCIXXQr_HS8=.5c56bafd-f0d4-463a-a746-3a0cbdaa930b@github.com>
Message-ID: <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@github.com>

On Mon, 28 Oct 2024 14:40:44 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](https://github.com/user-attachments/files/17517412/sample.txt)
>
> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes from review

Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?)

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 79:

> 77:       char buf[PATH_MAX];
> 78:       buf[0] = 0;
> 79:       proc_regionfilename(getpid(), (uint64_t) _address, buf, sizeof(buf));

I'd probably guard after the API call, just to be sure, with `buf[sizeof(buf)-1] = '\0'`. I could not find a description of this API anywhere, so no idea what its rules about zero termination are when buffer overflows.

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 101:

> 99:     if (valid_share_mode) {
> 100:       int share_mode = rinfo.pri_share_mode;
> 101:       //share_mode = share_mode == SM_LARGE_PAGE || share_mode == SM_PRIVATE_ALIASED ? SM_PRIVATE;

remnant?

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 196:

> 194: 
> 195:     bool is_private = region_info.pri_share_mode == SM_PRIVATE || region_info.pri_share_mode == SM_PRIVATE_ALIASED;
> 196:     bool is_shared = region_info.pri_share_mode == SM_SHARED || region_info.pri_share_mode == SM_SHARED_ALIASED || region_info.pri_share_mode == SM_TRUESHARED || region_info.pri_share_mode == SM_COW;

give us a line break :-) ?

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 212:

> 210:     }
> 211: 
> 212:     st->print_cr("Number of mappings: %u", _num_mappings);

If you reshuffle the lines (move this up), you can combine the conditions for err_vm ==/!= KERN_SUCCESS into one statement, would be easier to read

src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 336:

> 334: }
> 335: 
> 336: #endif // __APPLE__

whitespace error?

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 180:

> 178:             macOSbase + macprivate + space + someNumber + space + "META.*",
> 179:             // parts of metaspace should be uncommitted
> 180:             //regexBase + "-" + space + "META.*",

?? remnant

-------------

PR Review: https://git.openjdk.org/jdk/pull/20953#pullrequestreview-2401027472
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820295899
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820296647
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820297843
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820299881
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820291338
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820301511

From dholmes at openjdk.org  Tue Oct 29 08:32:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 08:32:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
Message-ID: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>

On Mon, 28 Oct 2024 23:09:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.
>
> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
> 
> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820337946

From alanb at openjdk.org  Tue Oct 29 08:35:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 08:35:27 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v16]
In-Reply-To: <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
Message-ID: <QfnAMvU5N9339gTdAtHifJJdgdIuhkrM6kKNp7AXrYU=.a779e739-afc5-47f2-bd9b-621071607182@github.com>

On Tue, 29 Oct 2024 08:32:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: one more correction in the annotated method description

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2401103908

From sspitsyn at openjdk.org  Tue Oct 29 08:35:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 08:35:27 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v16]
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: one more correction in the annotated method description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21397/files
  - new: https://git.openjdk.org/jdk/pull/21397/files/826adc7c..35ab0391

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21397&range=14-15

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21397/head:pull/21397

PR: https://git.openjdk.org/jdk/pull/21397

From sspitsyn at openjdk.org  Tue Oct 29 08:35:27 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 08:35:27 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v15]
In-Reply-To: <QuxVo6cfFZ0Ip274SSCVGhBoRSaPhQONLaFv1sxU77U=.7a62f7da-79d0-48b6-a6e4-4f2599c2e224@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <V6ky6GzX3j3Fqqb_Ri5Y4xcImGTxegQb6A_0xpxUg2M=.583b6ec0-fc49-4a7d-8cb4-4121bd9418e1@github.com>
 <QuxVo6cfFZ0Ip274SSCVGhBoRSaPhQONLaFv1sxU77U=.7a62f7da-79d0-48b6-a6e4-4f2599c2e224@github.com>
Message-ID: <ScV44_ezMLlS9_YOsXuNKYZtFs-gP9s9YApzWhcBg4I=.3509a722-5609-4813-a346-6066a20f0af4@github.com>

On Tue, 29 Oct 2024 06:45:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: tweak description of the annotation class JvmtiHideEvents
>
> src/java.base/share/classes/jdk/internal/vm/annotation/JvmtiHideEvents.java line 32:
> 
>> 30: /**
>> 31:  * A method may be annotated with JvmtiHideEvents to hint the JVMTI events
>> 32:  * should not be generated in context of the annotated method.
> 
> The sentence isn't quite right. I think you want to say that it's "a hint that JVMTI events" or "to hint that JVMTI events".

Thank you. Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21397#discussion_r1820336422

From dholmes at openjdk.org  Tue Oct 29 09:51:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 09:51:10 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Hotspot changes look good. May be some further cleanup possible. A couple of queries.

Thanks

src/hotspot/os/windows/os_windows.cpp line 2615:

> 2613:   Thread* t = Thread::current_or_null_safe();
> 2614: 
> 2615: #if defined(_M_AMD64)

The check for LP64 on line 2622 below seems redundant now

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 87:

> 85:     volatile Thread* wrapperthread = thread;
> 86: 
> 87:     if (os::win32::get_thread_ptr_offset() == 0) {

I think `os::win32::get_thread_ptr_offset` is not needed now and  ./os_cpu/windows_x86/assembler_windows_x86.cpp looks like it can be deleted.

src/hotspot/share/adlc/adlc.hpp line 49:

> 47: #define strdup _strdup
> 48: 
> 49: #ifndef _INTPTR_T_DEFINED

This seems unnecessary these days.

src/hotspot/share/prims/jvm.cpp line 381:

> 379:   {
> 380: #undef CSIZE
> 381: #if defined(_LP64)

Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?

src/hotspot/share/prims/nativeLookup.cpp line 350:

> 348:   if (entry != nullptr) return entry;
> 349: 
> 350:   // 3) Try JNI short style without os prefix/suffix

Please update comment as there is no os prefix/suffix now

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:

> 53: #error unsupported platform
> 54: #endif
> 55: 

Does Windows Aarch64 define _LP64?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2401144686
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820386150
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820407428
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820429621
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820433973
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820436924
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820441749

From shade at openjdk.org  Tue Oct 29 09:51:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 09:51:12 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
Message-ID: <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>

On Mon, 28 Oct 2024 23:15:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Launcher.gmk line 56:
>> 
>>> 54:   $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>>> 55:       NAME := jaccessinspector, \
>>> 56:       EXTRA_SRC := \
>> 
>> I might be missing something here. Original block has `SRC` parameter, do we not need it anymore?
>> 
>> Similar thing in `BUILD_JACCESSWALKER` and `BUILD_LIBJAVAACCESSBRIDGE` below.
>
> I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.

OK, good, as long as it was intentional.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820460415

From dholmes at openjdk.org  Tue Oct 29 09:51:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 09:51:13 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <5UIUxZr0j3KNUku45HGyyODTkrCo26CzAUr2zz0olnc=.22a6293d-0cd8-4fde-9832-ddcc539e4556@github.com>

On Mon, 28 Oct 2024 19:17:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os/windows/os_windows.cpp line 136:
> 
>> 134:   #define __CPU__ amd64
>> 135: #else
>> 136:   #define __CPU__ unknown
> 
> Should this be just `#error Unknown CPU`?

+1

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820365629

From jwaters at openjdk.org  Tue Oct 29 09:55:07 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 09:55:07 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>

On Tue, 29 Oct 2024 09:32:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/share/prims/jvm.cpp line 381:
> 
>> 379:   {
>> 380: #undef CSIZE
>> 381: #if defined(_LP64)
> 
> Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?

It's something we do in our build. For us, _LP64 really means 64 bit

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820464097

From dholmes at openjdk.org  Tue Oct 29 09:58:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 29 Oct 2024 09:58:04 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
 <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
Message-ID: <Q2ilzhuMavFzjle9mXD7ya4x8Dnoe9pg5RzpiDGFVXY=.795be851-06d9-4a7f-8a77-7be3a9d2ad19@github.com>

On Tue, 29 Oct 2024 00:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 
>> 
>> 
>> 
>>>     ExceptionCheck
>>>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
>>> 
>>>     jboolean ExceptionCheck(JNIEnv *env);
>>> 
>>>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address other cases in Hotspot

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21724#pullrequestreview-2401335566

From fbredberg at openjdk.org  Tue Oct 29 10:09:32 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Tue, 29 Oct 2024 10:09:32 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
Message-ID: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>

On Fri, 25 Oct 2024 13:11:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
>> 
>>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>>> 2032:     __ push_cont_fastpath();
>> 
>> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?
>
> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820487130

From alanb at openjdk.org  Tue Oct 29 10:40:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 10:40:14 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 246:

> 244:             CloseHandle(hProcess);
> 245:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException",
> 246:                 "Unable to attach to 32-bit process running under WOW64");

The comment just before this will need to be updated as the scenario as the tool side will always be 64-bit and just need to handle a 32-bit target VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820548857

From stooke at openjdk.org  Tue Oct 29 11:18:20 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 11:18:20 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@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>
Message-ID: <SW930-l-MESqI9nKmhqyidHgt9-hongB-TlrPqT27Iw=.ad97e142-abbe-4bc5-b010-6bf8cc64bd27@github.com>

On Tue, 29 Oct 2024 07:56:42 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes from review
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 79:
> 
>> 77:       char buf[PATH_MAX];
>> 78:       buf[0] = 0;
>> 79:       proc_regionfilename(getpid(), (uint64_t) _address, buf, sizeof(buf));
> 
> I'd probably guard after the API call, just to be sure, with `buf[sizeof(buf)-1] = '\0'`. I could not find a description of this API anywhere, so no idea what its rules about zero termination are when buffer overflows.

Good idea.

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 101:
> 
>> 99:     if (valid_share_mode) {
>> 100:       int share_mode = rinfo.pri_share_mode;
>> 101:       //share_mode = share_mode == SM_LARGE_PAGE || share_mode == SM_PRIVATE_ALIASED ? SM_PRIVATE;
> 
> remnant?

gone.

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 196:
> 
>> 194: 
>> 195:     bool is_private = region_info.pri_share_mode == SM_PRIVATE || region_info.pri_share_mode == SM_PRIVATE_ALIASED;
>> 196:     bool is_shared = region_info.pri_share_mode == SM_SHARED || region_info.pri_share_mode == SM_SHARED_ALIASED || region_info.pri_share_mode == SM_TRUESHARED || region_info.pri_share_mode == SM_COW;
> 
> give us a line break :-) ?

done.

> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 336:
> 
>> 334: }
>> 335: 
>> 336: #endif // __APPLE__
> 
> whitespace error?

Deleted line 335

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820598566
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820602981
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820601728
PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820598286

From stooke at openjdk.org  Tue Oct 29 11:29:07 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 11:29:07 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@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>
Message-ID: <86ZD34bF8Z4BVsdFax9Iw0anJuVwUAhVUvxqm2rexKY=.07293423-c3e2-4ce2-bd77-8e5fe2c2f25a@github.com>

On Tue, 29 Oct 2024 08:01:13 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes from review
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 180:
> 
>> 178:             macOSbase + macprivate + space + someNumber + space + "META.*",
>> 179:             // parts of metaspace should be uncommitted
>> 180:             //regexBase + "-" + space + "META.*",
> 
> ?? remnant

Gone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820617074

From stooke at openjdk.org  Tue Oct 29 11:32:09 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 11:32:09 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@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>
Message-ID: <tU3jwbXkqt838DJSIGjXXYjS5EvNHwKAKAKxYVwMcew=.cc8e9820-be5b-425c-b409-872d3f566cce@github.com>

On Tue, 29 Oct 2024 07:59:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changes from review
>
> src/hotspot/os/bsd/memMapPrinter_macosx.cpp line 212:
> 
>> 210:     }
>> 211: 
>> 212:     st->print_cr("Number of mappings: %u", _num_mappings);
> 
> If you reshuffle the lines (move this up), you can combine the conditions for err_vm ==/!= KERN_SUCCESS into one statement, would be easier to read

Done. My thinking was to separate the information gathering from the display code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20953#discussion_r1820621330

From stooke at openjdk.org  Tue Oct 29 11:42:27 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 11:42:27 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v3]
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: <jsP2PR20tIFbGkCaPuKC1f5vZfVaqLyks3d0rJJi_3s=.66a74135-dca1-4405-a4dd-447336f84cb0@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](https://github.com/user-attachments/files/17517412/sample.txt)

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  changes from review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/7bbb03da..a16cc7b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=01-02

  Stats: 26 lines in 2 files changed: 9 ins; 12 del; 5 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 stefank at openjdk.org  Tue Oct 29 12:16:33 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 29 Oct 2024 12:16:33 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v53]
In-Reply-To: <LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <LDg0GvC9lXkYPS90d9w8QfkTWlztUa5tlsgblGywCc4=.78ab2a17-2e28-4c27-b026-cd694ec02e21@github.com>
Message-ID: <IoELh3tHR8eEK8ZJfXgd1VBulpypTeLXAS7Nqkw_uJ4=.c2e38997-4be2-412d-a01d-5017d970a49f@github.com>

On Thu, 24 Oct 2024 21:04:51 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Enable riscv in CompressedClassPointersEncodingScheme test

src/hotspot/share/oops/markWord.inline.hpp line 29:

> 27: 
> 28: #include "oops/compressedOops.inline.hpp"
> 29: #include "oops/markWord.hpp"

I found this nit while looking around the code.
Suggestion:

#include "oops/markWord.hpp"

#include "oops/compressedOops.inline.hpp"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1820682388

From stooke at openjdk.org  Tue Oct 29 12:17:45 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 12:17:45 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v4]
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: <e4rkhkwRCLUczi3J3dBz9UV9qeXFc6KP-7tzwSPwr9w=.c1d1f8d4-66e9-4f25-a5eb-d685fc66df7a@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](https://github.com/user-attachments/files/17517412/sample.txt)

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  fix trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/a16cc7b0..a3a1a873

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=02-03

  Stats: 1 line in 1 file changed: 0 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 mullan at openjdk.org  Tue Oct 29 12:40:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:40:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Update copyrights. Remove @compile line form Marshal.java test.
 - Update copyright headers
 - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
 - Merge branch 'master' into jep486
 - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
 - remove privileged calls in logging/File* tests
 - delete PermissionTest.java as it simply constructs provider impls
 - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
 - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
   Removed createPrivateValue(), no longer used.
 - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=04
  Stats: 66378 lines in 1872 files changed: 1145 ins; 61413 del; 3820 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From mullan at openjdk.org  Tue Oct 29 12:51:59 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:51:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v2]
In-Reply-To: <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <WsVrP7NX4SnmjYF2Ua_jZPZUANBzRl0Tf5oVabn0MJc=.b7ed9f1d-5884-49b8-89e1-db483a2863a7@github.com>
 <qNOYR_KPQWUoOzfecn9_0Sep4qdK0kvkXJy1__Gp9Kw=.b09a3b4b-ba0b-4113-a3ef-4921d6a45608@github.com>
Message-ID: <InHcapZDPzV248KM-JZkB0e6iBp-skpVNJXkDdYazH0=.dd390d4d-e66f-4139-900a-a10410385483@github.com>

On Sun, 27 Oct 2024 00:15:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 97 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Change apiNote to deprecated annotation on checkAccess methods. Change method dedescription to "Does nothing".
>>  - Sanitize the class descriptions of DelegationPermission and ServicePermission
>>    by removing text that refers to granting permissions, but avoid changes that
>>    affect the API specification, such as the description and format of input
>>    parameters.
>>  - Restored methods in RMIConnection to throw SecurityExceptions again but
>>    with adjusted text that avoids the word "permission".
>>  - Add text to class description of MBeanServer stating that implementations
>>    may throw SecurityException if authorization doesn't allow access to resource.
>>  - Restore text about needing permissions from the desktop environment in the
>>    getPixelColor and createScreenCapture methods.
>>  - Add api note to getClassContext to use StackWalker instead and
>>    add DROP_METHOD_INFO option to StackWalker.
>>  - Change checkAccess() methods to be no-ops, rather than throwing
>>    SecurityException.
>>  - Merge
>>  - Merge
>>  - ... and 87 more: https://git.openjdk.org/jdk/compare/f50bd0d9...f89d9d09
>
> src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 93:
> 
>> 91:  * static {@link ThreadLocal} instance.  Authors of such implementations are
>> 92:  * <i>strongly</i> encouraged to determine the user at the time preferences
>> 93:  * are accessed (for example by the {@link #get(String,String)} or {@link
> 
> Most of this seems like it will remain applicable. Of course we won't suggest throwing `SecurityException`. But users not having sufficient OS-level privileges will still need to be addressed, yes?

This text was restored. See https://github.com/openjdk/jdk/pull/21498/commits/66145173cce201b655845144daa209a75ad5964a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820732961

From mullan at openjdk.org  Tue Oct 29 12:52:02 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:02 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <WtTk6-HHt037cI-2dFzi2Xsah_0A7ceHMYjo_UI8t10=.7b75bce3-ff04-4cf5-a854-7cc54f4f94d1@github.com>

On Fri, 25 Oct 2024 19:55:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/PluggableLocale/PermissionTest.java line 52:
> 
>> 50: import com.foo.NumberFormatProviderImpl;
>> 51: 
>> 52: public class PermissionTest{
> 
> This test can be deleted entirely. What remains is just constructing each provider impl.
> The summary mentions a RuntimePermission and would need to be revised to a new description.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/8054d108fea3ce9e7f1618c3d90ef5af6cfa22d7

> test/jdk/java/util/logging/FileHandlerLongLimit.java line 157:
> 
>> 155:     static class Configure {
>> 156:         static void setUp(Properties propertyFile) {
>> 157:             doPrivileged(() -> {
> 
> The doPrivileged() could be factored out.
> And callPrivileged().

These are all fixed in https://github.com/openjdk/jdk/pull/21498/commits/bc5b3d70741505a684a39474630372a9b2fd8bc0

> test/jdk/java/util/logging/TestLogConfigurationDeadLockWithConf.java line 83:
> 
>> 81:      * then the test is considered a success and passes.
>> 82:      *
>> 83:      * Note that 4sec may not be enough to detect issues if there are some.
> 
> Where is this timeout enforced or measured; this is just a comment, not a parameter.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/2a9b98e244362dbbb98487098865cfd46a46dc1e

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820722883
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820727624
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820725397

From mullan at openjdk.org  Tue Oct 29 12:52:03 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:52:03 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <kvSkNGGzpjSCrqcFcn_IfCM4LgffbPzAtH1WX1jHnmY=.da6d0dea-5296-4604-964c-f87b81486392@github.com>

On Fri, 25 Oct 2024 20:07:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/java/util/ResourceBundle/modules/security/src/test/jdk/test/Main.java line 48:
> 
>> 46:             throw new RuntimeException("unexpected resource bundle");
>> 47:         }
>> 48: 
> 
> This main and TestPermission.java duplicate the basic resource location mechanisms.
> This test/Main.java an test/TestPermission can be removed entirely.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/cb5f6e43b891df8c2a977e665016079469290669

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820730316

From stooke at openjdk.org  Tue Oct 29 12:57:00 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 12:57:00 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v5]
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: <84fr0AB57H9dU3b9q6ZEUMO2RQh87_T1Z7tsiXbvd4A=.fa2dab5a-e788-4dca-96fa-8f7bc01d7164@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](https://github.com/user-attachments/files/17517412/sample.txt)

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  fix xcode 16.1 compile error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/a3a1a873..6e368aed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=03-04

  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 mullan at openjdk.org  Tue Oct 29 12:59:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <OHRTqyW7xaw-Y8wWg1m-gR9uXBagHFeebliVkYz9-Lg=.15704ce2-88b6-4d3e-81ba-e2f3765a761c@github.com>
 <IuOyN9-FekeTa8Ag92-K13_xFOusPtgAHpVXlhdysi0=.ddff2cf3-1df7-4c32-9ac7-c19f389215a2@github.com>
Message-ID: <-KKpAuNUa1hNQE1tPbw9tlG5LKTTS-L9r5_YSJNhAFw=.10315724-126e-42bc-a933-8cd854efc163@github.com>

On Tue, 29 Oct 2024 06:32:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Executors.java line 529:
>> 
>>> 527:      * execute the given {@code callable} under the current access
>>> 528:      * control context, with the current context class loader as the
>>> 529:      * context class loader. This method should normally be invoked
>> 
>> We no longer state that the context class loader will be set when the callable is called, though the returned Callable _will_ still set the ccl. Is this OK?
>
> That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this.
> 
> Update: now fixed in sandbox

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/0feceaae472710aa13e4c569f4d72d6149b7de07

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820738332

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <9nyF6shPmWaMMGsOnjrzYKlZApNJV1uhY-tsTQhi_-M=.021bd5d0-f978-4651-97d6-0ab3f7cb2eaf@github.com>

On Mon, 28 Oct 2024 21:02:44 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/TransformService/NullParent.java line 1:
> 
>> 1: /*
> 
> Missed a copyright update; will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743852

From mullan at openjdk.org  Tue Oct 29 12:59:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 29 Oct 2024 12:59:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>

On Mon, 28 Oct 2024 21:00:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:
> 
>> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
>> 29:  * @compile -XDignore.symbol.file Marshal.java
>> 30:  * @run main/othervm/java.security.policy==test.policy Marshal
> 
> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.
> 
> Also, missing a copyright update, will fix.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820743569

From amitkumar at openjdk.org  Tue Oct 29 13:12:34 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 29 Oct 2024 13:12:34 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v50]
In-Reply-To: <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <F8pi_T7-BZh5Junuk22zJ5d9PnBRUs94urSreD5oH1c=.63e9a189-5d9a-45ca-a70c-53cf677627d9@github.com>
 <QirAyr5mX2p_jDtPINJsXF8Dv5p2Y_T5Dj2aTqEX-5I=.e1d5c692-81f8-4611-acde-eea1ad6313cd@github.com>
Message-ID: <BMnEQkyopmAU46K23jp9I-EuIjqrWgd3eNnQTgqTMVE=.055b1538-96bc-47e4-836b-f2f294b7686c@github.com>

On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright
>>  - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case.

@rkennke can you include this small update for s390x as well: 

```diff 
diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
index 0f7e5c9f457..476e3d5daa4 100644
--- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
@@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate(
 void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) {
   assert_different_registers(obj, klass, len, t1, Rzero);
   if (UseCompactObjectHeaders) {
-    z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset())));
-    z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes()));
+    z_mvc(
+          Address(obj, oopDesc::mark_offset_in_bytes()),  /* move to */
+          Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */
+          sizeof(markWord) /* how much to move */
+        );
   } else {
     load_const_optimized(t1, (intx)markWord::prototype().value());
     z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes()));
diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
index 378d5e4cfe1..c5713161bf9 100644
--- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
@@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src)
   // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract
   // obj-start, so that we can load from the object's mark-word instead.
   z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes()));
-  z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra
+  z_srlg(dst, dst, markWord::klass_shift);
 }
 
 //------------------------------------------------------
diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp
index 3cb1aba810d..5b8f7a20478 100644
--- a/src/hotspot/cpu/s390/templateTable_s390.cpp
+++ b/src/hotspot/cpu/s390/templateTable_s390.cpp
@@ -3980,8 +3980,11 @@ void TemplateTable::_new() {
     // Initialize object header only.
     __ bind(initialize_header);
     if (UseCompactObjectHeaders) {
-      __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset())));
-      __ z_stg(tmp, Address(RallocatedObject, oopDesc::mark_offset_in_bytes()));
+      __ z_mvc(
+            Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), // move to
+            Address(iklass, in_bytes(Klass::prototype_header_offset())), // move from
+            sizeof(markWord) // how much to move
+          );
     } else {
       __ store_const(Address(RallocatedObject, oopDesc::mark_offset_in_bytes()),
                      (long) markWord::prototype().value());

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2444180131

From jwaters at openjdk.org  Tue Oct 29 13:17:16 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 13:17:16 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
Message-ID: <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>

On Tue, 29 Oct 2024 06:59:22 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
> 
>> 26: #include "runtime/sharedRuntime.hpp"
>> 27: 
>> 28: #ifdef _WIN64
> 
> Just a heads up: Due to a bug, this entire file is never used at all

I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820776554

From jwaters at openjdk.org  Tue Oct 29 13:30:23 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 13:30:23 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port
In-Reply-To: <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
Message-ID: <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>

On Mon, 28 Oct 2024 19:25:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:
> 
>> 521: 
>> 522: extern "C" int SpinPause () {
>> 523: #ifdef AMD64
> 
> Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.

@shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820797875

From michaelm at openjdk.org  Tue Oct 29 13:44:31 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 29 Oct 2024 13:44:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <Q1jPK8TnNv45P679HTgjg5q6q7BtdKvBymZQv4GCAug=.605e003e-9d6e-45f7-815c-1e8e5ff70959@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

I have reviewed the changes to the NIO selector/poller implementations and they look fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2444268747

From stooke at openjdk.org  Tue Oct 29 14:09:07 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 14:09:07 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v6]
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: <M02L6RvOdWynraCxoUeQumuS-sLeF082SbypziUyeEg=.2816e437-cdbb-4d48-90f2-d47ef379cb31@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](https://github.com/user-attachments/files/17517412/sample.txt)

Simon Tooke has updated the pull request incrementally with one additional commit since the last revision:

  fix test for ZGC

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20953/files
  - new: https://git.openjdk.org/jdk/pull/20953/files/6e368aed..8e19b687

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=04-05

  Stats: 3 lines in 1 file changed: 2 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 stooke at openjdk.org  Tue Oct 29 14:12:10 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 29 Oct 2024 14:12:10 GMT
Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2]
In-Reply-To: <ulqfHx6SWsg4_LVUICfU1zgYNLKl71zBKFuvkq84ieI=.70b5bacf-0930-435b-a239-d8b8247ff1e7@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>
Message-ID: <hHc_uMM73sfJVW8b2SsppFb-l2pUPcSRfeuWa5l4UhI=.733bdc4e-d03e-484d-9bb6-b01fbb856bf9@github.com>

On Tue, 29 Oct 2024 08:01:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?)

Sample output for G1 and ZGC has been attached to the description (and I fixed the ZGC test)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2444382874

From weijun at openjdk.org  Tue Oct 29 14:22:54 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 29 Oct 2024 14:22:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
Message-ID: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>

On Mon, 28 Oct 2024 21:02:00 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Specify that params passed to getPermissions and implies are ignored and
>>    implies always returns false.
>>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>>  - clientlibs: Updated Problemlist
>>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>>  - clientlibs: Deleted JPopupMenu tests
>>    The following tests are deleted as they don't hold value without SM
>>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>>    always-on-top for apps which doesn't hold value after SM removal.
>>    
>>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>>    Works differently on macOS and windows & linux but this is the expected behavior.
>>    Details in JDK-8342012. Not a functional issue.
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>>    test renamed, test summary updated
>>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698
>
> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
> 
>> 1: /*
> 
> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?

It can removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820899380

From ihse at openjdk.org  Tue Oct 29 14:37:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:37:47 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v2]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <_vqxOwL91CU11rCTQQDOqQTaQmT6MryYl0X_wFrOVRw=.93503265-4579-4bb5-9bff-988ba152d96f@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove FIXMEs on x86 code that will soon go away anyway
 - Remove FIXME for issue resolved in JDK-8343167

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/a18d19c7..d5280f6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=00-01

  Stats: 4 lines in 3 files changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 14:42:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <cYhrCQkjiAdTPD_4Y3W8rTM8dN4g1k59uFa2baQidB0=.59fa5c79-92bd-444d-9885-0952d32286a0@github.com>
 <azLqOVxNhMl2IO1_AgP_RJrHQ8D_Cfh-euOZsD3-V8c=.dd315f9d-2285-4b3e-a746-dae44a0d20c6@github.com>
Message-ID: <EwBP8hZ_FRKS-4_Ga6GcYopwl-WcmnxB-E2SIso6JK0=.11afda7a-8fa7-44d5-a466-58a496067e65@github.com>

On Tue, 29 Oct 2024 09:48:52 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I think it was needed when the name didn't match the src dir, due to the `$1` suffix, but now we don't have that complication anymore.
>
> OK, good, as long as it was intentional.

Yes, Erik is correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820936242

From shade at openjdk.org  Tue Oct 29 14:42:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
Message-ID: <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>

On Tue, 29 Oct 2024 13:26:57 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 523:
>> 
>>> 521: 
>>> 522: extern "C" int SpinPause () {
>>> 523: #ifdef AMD64
>> 
>> Weird that SpinPause is not implemented on Win64, but oh well. This whole SpinPause mess should be arch-specific, not OS/Arch specific, probably.
>
> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR

Submit a separate PR and implement this :) Pretty sure you'll get into some dark territories in Windows/AArch64, see how Linux/AArch64 does this. But honestly, this whole `extern "C"` mess should probably be cleaned up in favor of arch-specific stubs or something like that...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820935020

From ihse at openjdk.org  Tue Oct 29 14:42:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:42:29 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <HB_BGygH9sWgvkyYjlKMuNV9saaCLojixNBvfRYF-As=.a2d3bb19-3856-429b-9957-f376471a8af7@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Use #error for unknown CPU
 - Restore PLATFORM_CHECK_DEPRECATION

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d5280f6d..c6b8771b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=01-02

  Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 14:47:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:47:15 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <00E4U7j0BVISX_UTyyRG0HuhLPMZ02LzIO5ofNx1Tis=.047ad177-0075-4a5c-83e2-ab6e792f2fb6@github.com>
Message-ID: <JRryi28SiFM4QgEO9CcGegJJ4j3cPSEE_Z-IjJE_gkM=.aa94c03b-b08f-4c49-be7c-8b77a413136f@github.com>

On Mon, 28 Oct 2024 23:16:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>
> make/modules/jdk.accessibility/Lib.gmk line 34:
> 
>> 32: 
>> 33:   ##############################################################################
>> 34:   ## Build libjavaaccessbridge
> 
> Is double `##` intentional?

Well, yes and no. :-) I just copied the pattern I used elsewhere as a header to mark the output library name for `SetupJdkLibrary`. Now that you say this, I wonder why I started using `##`. Most of the places, but not all, use the double hash sign. Let's do this `##` for now as well, and then maybe I do another round of cross-makefile consistency and replace them all with single `#`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820945684

From dfuchs at openjdk.org  Tue Oct 29 14:47:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:47:17 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <5kPidtpO9u4Uq1Cjk3-caYGOFua3Q09ea4tO_2eVdKs=.90e9833e-9445-4545-93fc-f179230d6597@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Changes to System.LoggerFinder / System.getXxxLogger methods look good to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402138949

From ihse at openjdk.org  Tue Oct 29 14:47:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:47:16 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v3]
In-Reply-To: <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
Message-ID: <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>

On Tue, 29 Oct 2024 13:14:44 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
>> 
>>> 26: #include "runtime/sharedRuntime.hpp"
>>> 27: 
>>> 28: #ifdef _WIN64
>> 
>> Just a heads up: Due to a bug, this entire file is never used at all
>
> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown

What bug are you referring to that makes this file unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820946983

From dfuchs at openjdk.org  Tue Oct 29 14:52:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 14:52:13 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <cyX0-593hoAmv_MAHCQnjHRZFJywvIxuL4PTUWO7hLU=.82d77ccc-2e4f-4d7f-b2f9-08f07e3c9252@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I had a look at public classes in java/io; I am not a regular reviewer there but what I saw made sense to me. Changes to ObjectInputStream/ObjectOutputStream will need a more qualified Reviewer but I believe you have that already.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402160395

From ihse at openjdk.org  Tue Oct 29 14:58:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:49 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <UG02ofvpmG7U3kL6SDF5mrYdAwLWxIw9KB0Jt2_CKOA=.103e237e-2822-4c7f-a8fc-034f9763518c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

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 seven commits:

 - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
 - Merge branch 'master' into impl-JEP-479
 - Use #error for unknown CPU
 - Restore PLATFORM_CHECK_DEPRECATION
 - Remove FIXMEs on x86 code that will soon go away anyway
 - Remove FIXME for issue resolved in JDK-8343167
 - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port

-------------

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=03
  Stats: 1546 lines in 51 files changed: 66 ins; 1404 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 14:58:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <uXG3LZMkp8sbXbyPk_hCdTQw8lzshARy1wLw7_kuPjQ=.6ac51040-6926-4d6d-93a6-fb5f9c6710fd@github.com>

On Tue, 29 Oct 2024 09:46:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 seven commits:
>> 
>>  - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
>>  - Merge branch 'master' into impl-JEP-479
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>>  - Remove FIXMEs on x86 code that will soon go away anyway
>>  - Remove FIXME for issue resolved in JDK-8343167
>>  - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port
>
> Hotspot changes look good. May be some further cleanup possible. A couple of queries.
> 
> Thanks

@dholmes-ora 
> May be some further cleanup possible. 

If you have any suggestions, please let me know. Otherwise, we can clean it up afterwards as we encounter it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444509002

From jwaters at openjdk.org  Tue Oct 29 14:58:50 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
 <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
Message-ID: <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>

On Tue, 29 Oct 2024 14:44:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I stand corrected: I forgot about Windows/ARM64. To correct myself: Due to a bug, this file, which is meant for Windows/x64, is used by Windows/ARM64 instead. The consequences of this are unknown
>
> What bug are you referring to that makes this file unused?

https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095864.html

This file isn't unused, I misspoke. Instead, it is meant as the implementation of frem and drem for Windows x64, but due to a bug, it's potentially being wrongly used as the implementation of frem and drem for Windows/ARM64 instead

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820964150

From jwaters at openjdk.org  Tue Oct 29 14:58:50 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <g1NzaJv2mG503ilKak7_PF7l3D_uyPVYcnpL1bSnUSM=.1d37105a-6d13-48ab-aa20-9f170bb82184@github.com>
 <vP9jKjX83bamEgYSqrK2Bvi-YOVdET_pmUzIIj8oCVY=.7e5eaf59-2389-4259-ad17-fc67f8f80ebe@github.com>
 <wrOer-c9R44NiF_aO-nvAWQLgWBSIXSXp_XnCKYJ-z8=.d168723b-b0b6-4102-b10c-47a92080e1d0@github.com>
Message-ID: <37HicUYBndPMWYfp1hWhVu7aTZzgbnCq1LFJCafbooc=.83838f4d-fe0a-4daf-962e-00764a2d7af0@github.com>

On Tue, 29 Oct 2024 14:37:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev There _is_ a way to implement SpinPause on Windows/x64 though, if support is really as simple as a single pause instruction. Should I help implement this separately (After this PR is integrated, to avoid conflicts)? Although, the way SpinPause can be implemented is honestly so simple and trivial that @magicus could simply replace the entire body of this SpinPause with it in this PR
>
> Submit a separate PR and implement this :) Pretty sure you'll get into some dark territories in Windows/AArch64, see how Linux/AArch64 does this. But honestly, this whole `extern "C"` mess should probably be cleaned up in favor of arch-specific stubs or something like that...

Oh, I was thinking about Windows/x64, but I guess I can consider Windows/ARM64 too. I had a look at Linux/ARM64 actually, and it seems like it doesn't actually properly support SpinPause? It seems like it uses the overhead of a method call to "implement" SpinPause. I had a look at some example assembly that could potentially be used to implement it for Windows/ARM64, but I don't know if it's correct. If you want, we could continue this discussion elsewhere

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820959571

From ihse at openjdk.org  Tue Oct 29 14:58:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 14:58:50 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v4]
In-Reply-To: <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <QJUCY9LzzbUUgALI7rM6vGRli2FAGdsy9xgJtYLOkbc=.e72d0bc0-bc88-4dc7-80c4-7f0ba31fbee4@github.com>
Message-ID: <yHGkV7I39TGK9UnDK3bHAzR1o-J1R44RTjqtMFl38OU=.f2f6733f-bbe7-4363-b704-3c59b94ebb24@github.com>

On Tue, 29 Oct 2024 10:37:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 seven commits:
>> 
>>  - Update VirtualMachineImpl_openProcess since it only needs to care about 64-bit
>>  - Merge branch 'master' into impl-JEP-479
>>  - Use #error for unknown CPU
>>  - Restore PLATFORM_CHECK_DEPRECATION
>>  - Remove FIXMEs on x86 code that will soon go away anyway
>>  - Remove FIXME for issue resolved in JDK-8343167
>>  - 8339783: Implementation of JEP 479: Remove the Windows 32-bit x86 Port
>
> src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 246:
> 
>> 244:             CloseHandle(hProcess);
>> 245:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException",
>> 246:                 "Unable to attach to 32-bit process running under WOW64");
> 
> The comment just before this will need to be updated as the scenario as the tool side will always be 64-bit and just need to handle a 32-bit target VM.

Good catch. I also simplified the code, now that we know that our process is 64 bit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820966986

From dfuchs at openjdk.org  Tue Oct 29 15:03:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:03:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <MlrAktPp9rmUHEnK3fWUbAH3j7eY0jZ0AzLMzRbSo_0=.34e5e56f-ef85-46e5-a92d-717a95e7a38e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I have reviewed changes in the public classes in java/nio/channels and java/nio/channels/spi. They LGTM.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402192169

From ihse at openjdk.org  Tue Oct 29 15:05:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:05:08 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v5]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <xc9ltNT-rdGYdDu0ZqrW2crALMC7ebbR06McQYzcul4=.9a1da15f-a2f1-456e-93aa-3c35678afdfb@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix NativeLookup::lookup_entry

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/01675824..bfca62ea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=03-04

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 15:05:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:05:09 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v5]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <h7H4LK5VJzr9g1OkY2MRfS2m9uYuiAfJCIN-l7QCd6o=.1c385cf9-88c8-474f-809d-66f003f1bf39@github.com>

On Tue, 29 Oct 2024 09:34:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix NativeLookup::lookup_entry
>
> src/hotspot/share/prims/nativeLookup.cpp line 350:
> 
>> 348:   if (entry != nullptr) return entry;
>> 349: 
>> 350:   // 3) Try JNI short style without os prefix/suffix
> 
> Please update comment as there is no os prefix/suffix now

Actually, it was not just the comment that were wrong, it was the actual code ("if the comment and code don't agree, then most likely both are wrong").

The steps 3 and 4 were just 1 and 2 without the os prefix/suffix, which we do not need anymore. I removed 4 but for some reason I did not realize that I should remove 3 as well. And I kept an unnecessary `if (entry != nullptr) return entry;`...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820979841

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <k-eEHHXkyAYvaSww-guyHgnfZPcju5V0wakhdvPICXY=.d96a3d1d-c949-4937-b1d3-2cfe088040f8@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove windows-only code guarded by _LP64.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/bfca62ea..d7ceff48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=04-05

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>

On Tue, 29 Oct 2024 09:02:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove windows-only code guarded by _LP64.
>
> src/hotspot/os/windows/os_windows.cpp line 2615:
> 
>> 2613:   Thread* t = Thread::current_or_null_safe();
>> 2614: 
>> 2615: #if defined(_M_AMD64)
> 
> The check for LP64 on line 2622 below seems redundant now

Indeed, nice catch! I also found another place in this file that were guarded by `_LP64` that I removed. I also did a grep on `LP64` in `hotspot/os/windows`, but there were no more instances.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820994278

From ihse at openjdk.org  Tue Oct 29 15:11:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:11:27 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v6]
In-Reply-To: <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <l81kDR4TKYnEPfuvPgMvHtnjVUJO934oHbo3_bQg6_4=.648dd5a6-877c-4486-a894-858f88946a60@github.com>
 <elVQXChIXkRSyOzTk-hpr-9XU3g6CaVLxsr0Z0CCQ0g=.d58b0c63-b5ba-42bd-8111-c7656f4ee852@github.com>
 <wb2gQnSixpE7UD6Pg4muyAiNe0enT1WC9BZ4uUZ_3rI=.82c17d69-2884-4c86-a0ae-492656e0f17f@github.com>
 <EzG-pL6Bka1yoJ79HwOpHCsWTFbXrtF7wa3jBPa903E=.b2762977-2d33-4517-94ac-b95920648898@github.com>
Message-ID: <yQgyCT9A0hSBXlsdUnqqdcBzQEfwjmAsB61B9tiSbp8=.ea446cda-6125-45e8-a1a5-addab6adabe7@github.com>

On Tue, 29 Oct 2024 14:53:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> What bug are you referring to that makes this file unused?
>
> https://mail.openjdk.org/pipermail/hotspot-dev/2024-October/095864.html
> 
> This file isn't unused, I misspoke. Instead, it is meant as the implementation of frem and drem for Windows x64, but due to a bug, it's potentially being wrongly used as the implementation of frem and drem for Windows/ARM64 instead

Okay. I'll leave it to you to sort out that mess. :) But afaict from reading up on the discussion, this removal of `_WIN64` does not change anything in that respect, so I'll keep it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1820986323

From ihse at openjdk.org  Tue Oct 29 15:19:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:19:02 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v7]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <TRqrMAD-Pk6wNKVS4nls_GOxV-vNS_P7tADiYOda0JE=.5adf838c-92d3-467f-916e-f7655bf841a0@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove win32-specific implementation of MacroAssembler::get_thread

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d7ceff48..c69e804f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=05-06

  Stats: 41 lines in 2 files changed: 0 ins; 41 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 15:19:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:19:03 GMT
Subject: RFR: 8339783: Implementation of JEP 479: Remove the Windows 32-bit
 x86 Port [v7]
In-Reply-To: <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <RqMT5810cq4sQ2CpqLzDSdwKOkFzSNm85SZq9LkHP_Q=.ddabe079-0b5e-4857-a58b-75907bf9095a@github.com>
Message-ID: <tWm2tu5KM8KzVRFTLKQCQ_ld1ByLbgNf3PqSMcv3l3k=.5f9b14a8-1447-4653-b688-30bcf4caad3d@github.com>

On Tue, 29 Oct 2024 15:08:47 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 2615:
>> 
>>> 2613:   Thread* t = Thread::current_or_null_safe();
>>> 2614: 
>>> 2615: #if defined(_M_AMD64)
>> 
>> The check for LP64 on line 2622 below seems redundant now
>
> Indeed, nice catch! I also found another place in this file that were guarded by `_LP64` that I removed. I also did a grep on `LP64` in `hotspot/os/windows`, but there were no more instances.

... however, there is also `hotspot/os_cpu/windows_x86` to check, and there I also found another instance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821007811

From ihse at openjdk.org  Tue Oct 29 15:26:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:26:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v8]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <2dt6agS27uUAXYsVQh4B6qvuk0KNiouPyH9bQQv8Kiw=.bb927982-e3f8-4276-8068-b2f97508ce50@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove thread_ptr_offset remnants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/c69e804f..fdec8b1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=06-07

  Stats: 26 lines in 2 files changed: 0 ins; 26 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 15:29:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:29:20 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v8]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <LUMCIYXGDty5ON_qg-m5S7JM7jqppr2Rn_G4GMKJr3U=.02d9577e-b074-480f-99e0-79837b2d191b@github.com>

On Tue, 29 Oct 2024 09:16:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove thread_ptr_offset remnants
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 87:
> 
>> 85:     volatile Thread* wrapperthread = thread;
>> 86: 
>> 87:     if (os::win32::get_thread_ptr_offset() == 0) {
> 
> I think `os::win32::get_thread_ptr_offset` is not needed now and  ./os_cpu/windows_x86/assembler_windows_x86.cpp looks like it can be deleted.

I just redisovered this by myself from your previous comment. :) However, there were some more `thread_ptr_offset` I could remove.

`assembler_windows_x86.cpp` is heavily cut down, but can't be fully removed since it contains the Windows implementation of `MacroAssembler::int3()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821037756

From ihse at openjdk.org  Tue Oct 29 15:33:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:33:51 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v9]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Ukgge4Lp1838MvKUyBYfxuZnSZuhTSnBZZ_z8jhC3mQ=.3856c7ca-fc8a-4f65-9962-7e14b6c1c1b7@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clean up old Windows workarounds in adlc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fdec8b1f..e5673077

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=07-08

  Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 15:33:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:33:51 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v9]
In-Reply-To: <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
Message-ID: <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>

On Tue, 29 Oct 2024 09:37:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up old Windows workarounds in adlc
>
> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:
> 
>> 53: #error unsupported platform
>> 54: #endif
>> 55: 
> 
> Does Windows Aarch64 define _LP64?

Yes. As Julian says, it's something we set up in our builds:

  if test "x$FLAGS_CPU_BITS" = x64; then
    $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
    $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
  fi

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821060520

From dfuchs at openjdk.org  Tue Oct 29 15:39:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 29 Oct 2024 15:39:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <ytVM17GPcnPoj29Blt9_kjjl-DLdbG_ixtEsUzamNx8=.55080c4c-0e5b-4f23-8052-889754c55b2e@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

For the record I have also reviewed the changes in JNDI (sources + test) and HTTP server (sources, I did the test changes) and they look good to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2444638665

From ihse at openjdk.org  Tue Oct 29 15:54:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 15:54:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v10]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <fH9Jl-bVpl3jA6kajM66-sA2r0DZqzhJrHcsU-9fJ_w=.7492ce8b-024a-4823-88fc-65fb80415424@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  adlc build were missing _CRT_DECLARE_NONSTDC_NAMES

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/e5673077..afb50971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Tue Oct 29 16:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:01:49 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  IS_WIN64 is never used and can be completely removed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/afb50971..9df6cb93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From jwaters at openjdk.org  Tue Oct 29 16:07:26 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 16:07:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <vrcs6_LQPTzV0Qer4akLdyVLHDYPSnLZo7ghbX0PUzw=.de57d630-4d94-4e42-80be-1e964a492e61@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Just a heads up, don't merge master for the time being. I think 8341527 just broke the x86 assembler

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444710777

From ihse at openjdk.org  Tue Oct 29 16:07:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:07:27 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <jOSFV149kokCQvuprsHXfI74yE9iZ1B7pkKHYkna5OM=.a29556ce-7517-4b45-b1cd-69e9508c1005@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Yeah, this still needs JEP-479 to be targeted, so it some time away from being merged. :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444716198

From jwaters at openjdk.org  Tue Oct 29 16:16:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 29 Oct 2024 16:16:13 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <ktWFCYs7bD74riBdfCL7E1Y1cUYLh2IYq67MVeulTs8=.8eb18c32-ac62-48d2-8cb9-a9658d0cb4b7@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

Oh, I meant don't merge current master into the branch for this PR haha, you'll very likely get red all over your GHA from the broken assembler_x86.cpp failing to compile (From what I can tell, all x86 builds are affected)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2444736299

From alanb at openjdk.org  Tue Oct 29 16:16:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 29 Oct 2024 16:16:14 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v11]
In-Reply-To: <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MTFaHVUpicv6wmpnxAjNKREdc0qaMJJuYApMe2yZ00E=.79d4d906-44e8-4f88-928e-306e0067accd@github.com>
Message-ID: <w2A4lfSmBnNKSd2qB0q2TQvxB7209_sf9_q97k8enWk=.09b9ef8a-402a-4cb6-8160-73047fea80ff@github.com>

On Tue, 29 Oct 2024 16:01:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IS_WIN64 is never used and can be completely removed

src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c line 236:

> 234:      * On Windows we need to handle 32-bit tools trying to attach to 64-bit
> 235:      * processes, which is currently not supported by this implementation.
> 236:      */

The tool side uses the attach API so the potential scenario is a tool on 64-bit attempting to attach to a target VM that is 32-bit. So the comment needs to re-phased to the reverse of what it says now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821145158

From ihse at openjdk.org  Tue Oct 29 16:35:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 16:35:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v12]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <tMqPWYRUTPtyZmNJ4RkRM7eEw5OFs3_eXY1AyZNzoSU=.ffb49543-18df-4b01-8de0-391cd82dd751@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  adlc need _CRT_NONSTDC_NO_WARNINGS as well... *sigh*

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/9df6cb93..7eb46c33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=10-11

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From kevinw at openjdk.org  Tue Oct 29 16:44:11 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 29 Oct 2024 16:44:11 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v2]
In-Reply-To: <eDf5F2pVFsjBTfFbBTqBcije9ELLo09mX92NuCP9w_Y=.d92b6c7a-0ef5-4d47-b768-e4874fbd6fc8@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
 <eDf5F2pVFsjBTfFbBTqBcije9ELLo09mX92NuCP9w_Y=.d92b6c7a-0ef5-4d47-b768-e4874fbd6fc8@github.com>
Message-ID: <RcTcJimK5umYqk4V96jQzVq2JRgfC-S0EmmBWmEz1t8=.e2fede71-677b-422c-a587-487ef417d8cc@github.com>

On Mon, 28 Oct 2024 20:27:27 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the implementation I originally provided does not in fact solve the issue!
>> 
>> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
>> 
>> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
>> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
>> 
>> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
>> 
>> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
>> 
>> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
>> 
>> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
>> 
>> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
>> 
>> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
>> 
>> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
>> 
>> therefore an "attacher" has two choices when attempting to attach:
>> 
>> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>>   - this works with both peers and descendants
>> 
>> - use /tmp
>>   - this only works if the "attacher" and "attachee" share a /tmp in common
>> 
>> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
>> 
>> I...
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8342449: changed logic of attach loop to throw if target still not ready when timed out and consolidated comments

src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 114:

> 112:                         String.format("Unable to open socket file %s: " +
> 113:                           "target process %d doesn't respond within %dms " +
> 114:                           "or HotSpot VM not loaded", socket_path, time_spend));

Do we still need a pid argument after this format string?
time_spent would read more easily than "spend" 8-) but we had have that for years.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1821191477

From rriggs at openjdk.org  Tue Oct 29 16:54:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 16:54:59 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
Message-ID: <Pg9N43cJQ4mPhIHzrotEbgDy4oCc1OcfEDWoP9U8aVI=.11981767-6704-4655-beb0-7b6c7d7b8bc9@github.com>

On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Specify that params passed to getPermissions and implies are ignored and
>    implies always returns false.
>  - Change deprecated annotations to api notes on getPolicy and setPolicy.
>  - clientlibs: Updated Problemlist
>    Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was determined that it is not a JDK bug but expected behavior on windows and linux platform.
>  - clientlibs: Deleted JPopupMenu tests
>    The following tests are deleted as they don't hold value without SM
>    test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that the popup are
>    always-on-top for apps which doesn't hold value after SM removal.
>    
>    test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether popup can overlap taskbar.
>    Works differently on macOS and windows & linux but this is the expected behavior.
>    Details in JDK-8342012. Not a functional issue.
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>  - clientlibs: GetSoundBankSecurityException.java renamed to EmptySoundBankTest.java
>    test renamed, test summary updated
>  - Restore note for implementers in src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java
>  - Change "SecurityManager" to "Security Manager". Add some missing code and linkplain tags.
>  - Add api note to class description that permission checking is not supported and remove text about getting permissions from system policy. In getPermissions(), change "granted to the given codesource" to "for the codesource".
>  - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698

Reviewed java.sql and java.sql.rowset src and test; lgtm

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402558624

From honkar at openjdk.org  Tue Oct 29 17:10:54 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>

On Thu, 24 Oct 2024 15:03:23 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> src/java.desktop/share/classes/java/awt/Font.java line 1613:
> 
>> 1611:      * interpreted as a {@code Font} object according to the
>> 1612:      * specification of {@code Font.decode(String)}
>> 1613:      * If the specified property is not found then null is returned instead.
> 
> Suggestion:
> 
>      * If the specified property is not found, null is returned instead.
> 
> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.

Updated on jep486 branch

> src/java.desktop/share/classes/java/awt/Font.java line 1781:
> 
>> 1779:      * The property value should be one of the forms accepted by
>> 1780:      * {@code Font.decode(String)}
>> 1781:      * If the specified property is not found then the {@code font}
> 
> Suggestion:
> 
>      * If the specified property is not found, the {@code font}

Updated on jep486 branch

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821237100
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821236441

From honkar at openjdk.org  Tue Oct 29 17:10:55 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 29 Oct 2024 17:10:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>

On Thu, 24 Oct 2024 15:12:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:
> 
>> 66:      * @throws SecurityException if a security manager exists and its
>> 67:      *            {@code checkPermission} method doesn't allow the operation
>> 68:      * @see       GraphicsConfiguration
> 
> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?

You are right, I see it mentioned already in the doc. I don't think we need to mention it again?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821232103

From amenkov at openjdk.org  Tue Oct 29 18:12:08 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Oct 2024 18:12:08 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <OlpiRkIsVlANkkh7G9ToTnblgnBqTL_IGWBiC9w902I=.909dd972-afef-4746-abbf-ae7817ad9d7d@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
 <OlpiRkIsVlANkkh7G9ToTnblgnBqTL_IGWBiC9w902I=.909dd972-afef-4746-abbf-ae7817ad9d7d@github.com>
Message-ID: <5xCgOkJSfuTEfEsAqcY1EZ-fzKNrLwv_X8ZJW5cRT-c=.53c624b2-0b6d-43f8-84fa-ed7bfdcaf0dd@github.com>

On Tue, 29 Oct 2024 04:16:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Serguei explained in the parent bug why it is failing, so I'm not sure why you need the verbose output.

I disagree with the evaluation. We have a single failure with JTREG_TEST_THREAD_FACTORY=Virtual, most of the failures are without it. And JTREG_TEST_THREAD_FACTORY should not affect this test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21725#issuecomment-2445002195

From amenkov at openjdk.org  Tue Oct 29 18:14:16 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Oct 2024 18:14:16 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v16]
In-Reply-To: <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
Message-ID: <ciERdL59VX0ngr50q6lQFuZ6dUpKI3S88X1H8eD7y3Y=.cab0fe0c-ba4d-4dcb-9a0e-24fc81079199@github.com>

On Tue, 29 Oct 2024 08:35:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: one more correction in the annotated method description

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21397#pullrequestreview-2402752520

From wkemper at openjdk.org  Tue Oct 29 18:20:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Oct 2024 18:20:33 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <p7YVH0moyGyDlINK9wVZK4n-7Z5KCyI6kvmX8wkcgWs=.35c31ce4-595f-48a0-9902-6db8a3a70738@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
 <p7YVH0moyGyDlINK9wVZK4n-7Z5KCyI6kvmX8wkcgWs=.35c31ce4-595f-48a0-9902-6db8a3a70738@github.com>
Message-ID: <XvVvRtymTU72I7j6s2i-gJS6rWLAPGzuJbFAzW8JS_s=.0be3a91a-6bdf-4960-a8a6-b7d994d4c354@github.com>

On Sat, 26 Oct 2024 01:33:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
>> 
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8342560: GenShen: Fix confusing method name
>>    
>>    Reviewed-by: ysr
>>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>>    
>>    Reviewed-by: xpeng, ysr
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>>    
>>    Reviewed-by: ysr
>>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>>    
>>    Reviewed-by: ysr
>>  - 8342255: GenShen: Remove unnecessary enum initial values
>>    
>>    Reviewed-by: ysr
>>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408
>
> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 243:
> 
>> 241: void ShenandoahAgeCensus::update_tenuring_threshold() {
>> 242:   if (!ShenandoahGenerationalAdaptiveTenuring) {
>> 243:     _tenuring_threshold[_epoch] = InitialTenuringThreshold;
> 
> `InitialTenuringThreshold` is currently only used by parallel GC, so that the flag's constraint is only implemented in parallel GC [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp#L177) . Now, Shenandoah reuses the flag, you may want to consider to parallel GC's implementation into `shared`.

Good catch. https://bugs.openjdk.org/browse/JDK-8343226

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1821337048

From cjplummer at openjdk.org  Tue Oct 29 18:35:13 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 29 Oct 2024 18:35:13 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
Message-ID: <Zw5-kf4U0v2aotAfd8E0nIbH6pU7gWx37LngHH6QhZE=.7536e07b-574d-4cf8-b811-db6267b284a8@github.com>

On Fri, 25 Oct 2024 22:44:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix enables logging in the test agent to get more details about intermittent failures.

Approved and trivial.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21725#pullrequestreview-2402793552

From cjplummer at openjdk.org  Tue Oct 29 18:35:15 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 29 Oct 2024 18:35:15 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <5xCgOkJSfuTEfEsAqcY1EZ-fzKNrLwv_X8ZJW5cRT-c=.53c624b2-0b6d-43f8-84fa-ed7bfdcaf0dd@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
 <OlpiRkIsVlANkkh7G9ToTnblgnBqTL_IGWBiC9w902I=.909dd972-afef-4746-abbf-ae7817ad9d7d@github.com>
 <5xCgOkJSfuTEfEsAqcY1EZ-fzKNrLwv_X8ZJW5cRT-c=.53c624b2-0b6d-43f8-84fa-ed7bfdcaf0dd@github.com>
Message-ID: <IeJLiZI0lx5TGxkXoUivAjmflw7PrY5UImx6jDZlivs=.6f92eb97-8805-4fb9-a1a1-de475abeb015@github.com>

On Tue, 29 Oct 2024 18:09:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > Serguei explained in the parent bug why it is failing, so I'm not sure why you need the verbose output.
> 
> I disagree with the evaluation. We have a single failure with JTREG_TEST_THREAD_FACTORY=Virtual, most of the failures are without it. And JTREG_TEST_THREAD_FACTORY should not affect this test.

It would be good to note that in the parent CR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21725#issuecomment-2445046942

From bchristi at openjdk.org  Tue Oct 29 18:38:54 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 29 Oct 2024 18:38:54 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

`java.util` and `java.util.concurrent` src and test changes look good.

src/java.base/share/classes/java/util/concurrent/Executors.java line 392:

> 390:     /**
> 391:      * Returns a thread factory used to create new threads that
> 392:      * have current context class loader as the context class loader.

One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402793417
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1821358523

From wkemper at openjdk.org  Tue Oct 29 18:46:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Oct 2024 18:46:17 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <Rku187KbA-0dpP0fxJhyUnvODEyUPjHLWlEgkS-KGEU=.36fd6343-7cdd-4168-9944-fa52552139d2@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
 <Rku187KbA-0dpP0fxJhyUnvODEyUPjHLWlEgkS-KGEU=.36fd6343-7cdd-4168-9944-fa52552139d2@github.com>
Message-ID: <Of3TjfZ9Xf9VO9HbrRRe_Xi0n_1Rt6a9L5HpoP6Boss=.b2b19aef-a099-42f8-94ee-05c5a23c7fb9@github.com>

On Sat, 26 Oct 2024 02:05:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
>> 
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8342560: GenShen: Fix confusing method name
>>    
>>    Reviewed-by: ysr
>>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>>    
>>    Reviewed-by: xpeng, ysr
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>>    
>>    Reviewed-by: ysr
>>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>>    
>>    Reviewed-by: ysr
>>  - 8342255: GenShen: Remove unnecessary enum initial values
>>    
>>    Reviewed-by: ysr
>>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 701:
> 
>> 699:       // Seed the collection set with resource area-allocated
>> 700:       // preselected regions, which are removed when we exit this scope.
>> 701:       ResourceMark rm;
> 
> You can fold `ResourceMark` into `ShenandoahCollectionSetPreselector` class.

This makes sense: https://bugs.openjdk.org/browse/JDK-8343227

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1821368739

From rriggs at openjdk.org  Tue Oct 29 18:49:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Oct 2024 18:49:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <gYQw-g86W7MLIsSAkOIYq5Y3HjssUtl3_xxeYVHGV74=.3a600d88-7674-4014-bae5-65691f06af21@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

Reviewed java/util/jar,zip src and test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2402819301

From amenkov at openjdk.org  Tue Oct 29 18:54:04 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Oct 2024 18:54:04 GMT
Subject: RFR: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <IeJLiZI0lx5TGxkXoUivAjmflw7PrY5UImx6jDZlivs=.6f92eb97-8805-4fb9-a1a1-de475abeb015@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
 <OlpiRkIsVlANkkh7G9ToTnblgnBqTL_IGWBiC9w902I=.909dd972-afef-4746-abbf-ae7817ad9d7d@github.com>
 <5xCgOkJSfuTEfEsAqcY1EZ-fzKNrLwv_X8ZJW5cRT-c=.53c624b2-0b6d-43f8-84fa-ed7bfdcaf0dd@github.com>
 <IeJLiZI0lx5TGxkXoUivAjmflw7PrY5UImx6jDZlivs=.6f92eb97-8805-4fb9-a1a1-de475abeb015@github.com>
Message-ID: <2oM0Sisx95FAVOJANE7LNG4lH5TFNTO25D8HHL8weXM=.53daa415-1443-4dd8-96a5-55ec48df7717@github.com>

On Tue, 29 Oct 2024 18:32:10 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > > Serguei explained in the parent bug why it is failing, so I'm not sure why you need the verbose output.
> > 
> > 
> > I disagree with the evaluation. We have a single failure with JTREG_TEST_THREAD_FACTORY=Virtual, most of the failures are without it. And JTREG_TEST_THREAD_FACTORY should not affect this test.
> 
> It would be good to note that in the parent CR.

Yes, thank you. I added the comment

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21725#issuecomment-2445081618

From pchilanomate at openjdk.org  Tue Oct 29 18:57:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 18:57:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment in SharedRuntime::generate_native_wrapper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/056d21ec..3e8b4fe6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=15-16

  Stats: 15 lines in 3 files changed: 6 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 29 19:08:35 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:35 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Ja15_PHC0kruM7p7N25WA7zPWhc2ecAJsi5Q6jcwQ8Y=.3655f0c2-81fd-46a3-9a12-0cb3c86cfb45@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.c3bfedf8-67c6-4445-be26-082c0005d8ca@github.com>
 <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.46c50e52-3005-4ec7-8495-fcd58624eee2@github.com>
Message-ID: <S0IfxODyOvrNooBjR0lhlgrGg1zHFmID_7LfL0W8uFo=.5524316f-3234-492f-bd73-9a2a2c37fb21@github.com>

On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.
> 
> Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.
>
After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760

From pchilanomate at openjdk.org  Tue Oct 29 19:08:36 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
Message-ID: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>

On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>>
>> It will just move the task of adjusting the size of the frame somewhere else.
>
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
> 
> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:


   0xffffdfdba584:	sub	sp, sp, #0x10
   0xffffdfdba588:	stp	x29, x30, [sp]
   0xffffdfdba58c:	ldrb	w8, [x28, #1192]
   0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
   0xffffdfdba594:	mov	x8, #0x4ba0                	
   0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
   0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5a0:	mov	x0, x28
   0xffffdfdba5a4:	blr	x8
   0xffffdfdba5a8:	mov	x9, sp
   0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
   0xffffdfdba5b0:	mov	x0, x1
   0xffffdfdba5b4:	mov	x1, x2
   0xffffdfdba5b8:	mov	x2, x28
   0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
   0xffffdfdba5c0:	mov	x8, #0xe6a4                	
   0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
   0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
   0xffffdfdba5d0:	blr	x8
   0xffffdfdba5d4:	nop
   0xffffdfdba5d8:	movk	xzr, #0x0
   0xffffdfdba5dc:	movk	xzr, #0x0
   0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
   0xffffdfdba5e4:	str	xzr, [x28, #1000]
   0xffffdfdba5e8:	str	xzr, [x28, #1008]
   0xffffdfdba5ec:	ldr	x10, [x28, #8]
   0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
   0xffffdfdba5f4:	ldp	x29, x30, [sp]
   0xffffdfdba5f8:	add	sp, sp, #0x10
   0xffffdfdba5fc:	ret
   0xffffdfdba600:	ldp	x29, x30, [sp]
   0xffffdfdba604:	add	sp, sp, #0x10
   0xffffdfdba608:	adrp	x8, 0xffffdfc30000
   0xffffdfdba60c:	add	x8, x8, #0x80
   0xffffdfdba610:	br	x8

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821389434

From pchilanomate at openjdk.org  Tue Oct 29 19:08:37 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
Message-ID: <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>

On Tue, 29 Oct 2024 01:42:09 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
> 
>> 75:     // Interpreter frames
>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
> 
> This conflicts with sender_sp_offset.  Doesn't that cause a problem?

No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856

From pchilanomate at openjdk.org  Tue Oct 29 19:08:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <xk3axts-SpX_eKRsS6Y3rFGyiWoBLiERsuhtI7oReJE=.de9a7c06-de16-4622-8e81-3db0c3b3d778@github.com>
 <WNLditcfJiEBfFwrBb6RdpybeW4Hmqorlt5MKccgLSw=.49307547-7d5f-41fe-860f-904f1a023440@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.7f303a83-44f0-4f66-b952-ede53c0852c4@github.com>
 <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.8db81452-6e95-4a3a-92b7-b989a5ddb92b@github.com>
Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.98c3e8da-5fa4-4653-8254-a80b9c86ec8e@github.com>

On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.
>
> It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

I updated the comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821386261

From pchilanomate at openjdk.org  Tue Oct 29 19:08:38 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 19:08:38 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <IXtF9-0DIgpMGcbq_M44PRWoa28jWGyqWnY0E6HFprg=.c6d22d34-9021-4816-8ccd-13123a4e92db@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.6bf0e33d-afc3-473e-b35d-3d8e892487c6@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.0f330bcc-4774-4718-8c53-081d34c9855d@github.com>
 <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.ced6c6c0-3eda-4da3-b9a0-332cf609e6ae@github.com>
Message-ID: <E5BoDn6nBa-B8W6bUd-RciLLaEMNTcF4YVT2JlpCXGg=.71b49a14-9e2c-47a2-98d7-f4df8bbf7ae1@github.com>

On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
>> 
>> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.
>
> Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

It's not that straightforward because the freeze can fail. By then we would have already started the wait call as a virtual thread though, not a platform thread. Maybe we could try to freeze before the wait0 call. We always have the option to use a flag in the method as Dean suggests instead of checking for a specific one. Since now there is only `Object.wait()` I think it's better to explicitly check for it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821391532

From duke at openjdk.org  Tue Oct 29 19:13:08 2024
From: duke at openjdk.org (Larry Cable)
Date: Tue, 29 Oct 2024 19:13:08 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v2]
In-Reply-To: <RcTcJimK5umYqk4V96jQzVq2JRgfC-S0EmmBWmEz1t8=.e2fede71-677b-422c-a587-487ef417d8cc@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
 <eDf5F2pVFsjBTfFbBTqBcije9ELLo09mX92NuCP9w_Y=.d92b6c7a-0ef5-4d47-b768-e4874fbd6fc8@github.com>
 <RcTcJimK5umYqk4V96jQzVq2JRgfC-S0EmmBWmEz1t8=.e2fede71-677b-422c-a587-487ef417d8cc@github.com>
Message-ID: <MyHTgmKnBXNjalisrxtPbLHBBp5Utt0Iol1bvZCGQ68=.2aa30838-7a26-4e48-b292-5494c449d5b0@github.com>

On Tue, 29 Oct 2024 16:41:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8342449: changed logic of attach loop to throw if target still not ready when timed out and consolidated comments
>
> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 114:
> 
>> 112:                         String.format("Unable to open socket file %s: " +
>> 113:                           "target process %d doesn't respond within %dms " +
>> 114:                           "or HotSpot VM not loaded", socket_path, time_spend));
> 
> Do we still need a pid argument after this format string?
> time_spent would read more easily than "spend" 8-) but we had have that for years.

generally I dont think its a good idea to modify exception msgs ...

> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 330:
> 
>> 328:     private static final long SIGQUIT = 1L << 2;
>> 329: 
>> 330:     private static boolean checkCatchesAndSendQuitTo(int pid, boolean throwIfNotReady) throws AttachNotSupportedException, IOException {
> 
> Looks like the throwIfNotReady param is not needed, can be removed.

I changed the logic so that now when the timeout loop times out the last attempt to send the QUIT will throw if the target is not catching QUIT

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1821397298
PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1821400072

From amenkov at openjdk.org  Tue Oct 29 19:36:07 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 29 Oct 2024 19:36:07 GMT
Subject: RFR: 8342577: Clean up JVMTI breakpoint support
In-Reply-To: <Sq9cCqoc-SYEgRv1f6UXj1_3JE-BeHc5XR2JXKzi48A=.0b3917ad-6d1d-43f9-b3cb-26174df24705@github.com>
References: <JbSsksMFRTSKodRSJKPZVM99HM84BeAzpK4LqKFWPmY=.f276d4f4-a79c-40db-a86a-20cd6722ca86@github.com>
 <Sq9cCqoc-SYEgRv1f6UXj1_3JE-BeHc5XR2JXKzi48A=.0b3917ad-6d1d-43f9-b3cb-26174df24705@github.com>
Message-ID: <40Vr-91DelJl8D5s1b8FlFUFEJnnpmT2MH2FDllgfIg=.973f249c-a9f7-4e10-ad31-0e0e821753f8@github.com>

On Tue, 29 Oct 2024 04:31:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix cleans up code to support list of JVMTI breakpoints.
>> - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped;
>> - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code;
>> - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637);
>> - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor;
>> - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass;
>> 
>> Testing: tier1..tier6
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 208:
> 
>> 206: 
>> 207: JvmtiBreakpoints::JvmtiBreakpoints()
>> 208:     : _elements(5, mtServiceability) {
> 
> Do we have tests that create more than 5 breakpoints? I just want to make sure the array growing code is exercised. You could stress it by testing with the initial size set to 1.

This is the same we had before (in `GrowableCache::initialize`, old line 142):
`_elements       = new (mtServiceability) GrowableArray<GrowableElement*>(5, mtServiceability);`
I set the initial size to 1,  JDI tests (some of them have more than 1 breakpoint) passed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21675#discussion_r1821413575

From dlong at openjdk.org  Tue Oct 29 19:44:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 19:44:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <JjAMYDu2JWAGBmPXC8__9R4OhWr43Y-L5qksWcCJAzQ=.749fcb0e-2e47-4816-8564-ec23ad4d80d2@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324:

> 322:   movq(scrReg, tmpReg);
> 323:   xorq(tmpReg, tmpReg);
> 324:   movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset()));

I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823

From sspitsyn at openjdk.org  Tue Oct 29 20:03:28 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 20:03:28 GMT
Subject: RFR: 8341273: JVMTI is not properly hiding some continuation
 related methods [v16]
In-Reply-To: <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
 <1WJrkg2bxYTpmd7Z7FoVF3fF0gFDebrLe6S73LMjO-A=.8ca25b84-6d38-4c69-8640-58643141449c@github.com>
Message-ID: <LqkaAx8hDpjdjxb2fbPe3P73jYIvgqCDRl8rG6LypRM=.75de177f-9afc-4150-83f8-48806fe827ed@github.com>

On Tue, 29 Oct 2024 08:35:27 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
>> Please, see a fix description in the first comment.
>> 
>> Testing:
>>  - Verified with new test `vthread/CheckHiddenFrames`
>>  - Mach5 tiers 1-6 are passed
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: one more correction in the annotated method description

Alan and Alex, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21397#issuecomment-2445210765

From sspitsyn at openjdk.org  Tue Oct 29 20:03:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 29 Oct 2024 20:03:30 GMT
Subject: Integrated: 8341273: JVMTI is not properly hiding some continuation
 related methods
In-Reply-To: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
References: <WG0Aajbm42YVfVLMlnK_bIVk8V2n3v13sckrekMpJhU=.77c36c16-1220-43b9-b3e3-c3f96c3df47c@github.com>
Message-ID: <3VXdHrpClP20H82NAsimJEvs2la4xffI_PGbsAmag9k=.1b051269-3528-4bd1-8969-bb126f79e17a@github.com>

On Mon, 7 Oct 2024 22:03:36 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes a problem in the VTMS (Virtual Thread Mount State) transition frames hiding mechanism.
> Please, see a fix description in the first comment.
> 
> Testing:
>  - Verified with new test `vthread/CheckHiddenFrames`
>  - Mach5 tiers 1-6 are passed

This pull request has now been integrated.

Changeset: 60364ef0
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/60364ef0010bde2933c22bf581ff8b3700c4afd6
Stats:     367 lines in 15 files changed: 287 ins; 50 del; 30 mod

8341273: JVMTI is not properly hiding some continuation related methods

Reviewed-by: alanb, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/21397

From ihse at openjdk.org  Tue Oct 29 20:22:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 29 Oct 2024 20:22:03 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/7eb46c33..3556bec5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From dlong at openjdk.org  Tue Oct 29 20:42:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 20:42:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
Message-ID: <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>

On Tue, 29 Oct 2024 18:57:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in SharedRuntime::generate_native_wrapper

src/hotspot/share/code/nmethod.cpp line 712:

> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185

From dlong at openjdk.org  Tue Oct 29 20:45:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 20:45:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
Message-ID: <7IcqtCURSggJ3TfKrTorRcFaCrbLsWworFGrFolak7k=.8348725c-581b-4d75-ac69-db1b53386497@github.com>

On Tue, 29 Oct 2024 18:57:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment in SharedRuntime::generate_native_wrapper

src/hotspot/share/code/nmethod.cpp line 1302:

> 1300:     _compiler_type           = type;
> 1301:     _orig_pc_offset          = 0;
> 1302:     _num_stack_arg_slots     = 0;

Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576

From dlong at openjdk.org  Tue Oct 29 21:00:30 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:00:30 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
 <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
Message-ID: <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>

On Tue, 29 Oct 2024 19:04:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
>> 
>>> 75:     // Interpreter frames
>>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
>> 
>> This conflicts with sender_sp_offset.  Doesn't that cause a problem?
>
> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

`sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020

From dlong at openjdk.org  Tue Oct 29 21:35:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:35:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/oops/method.cpp line 870:

> 868: }
> 869: 
> 870: bool Method::is_object_wait0() const {

It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267

From dlong at openjdk.org  Tue Oct 29 21:49:31 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 21:49:31 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <7tWdvN9ESrXL9_I6SoEXaHFInONVH4WK9cCBv2mISUg=.6d6b1da1-18c1-4ff5-91d2-601db5aab0ed@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:

> 253:                          RegisterMap::WalkContinuation::include);
> 254:     full_map.set_include_argument_oops(false);
> 255:     closure->do_frame(f, map);

This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623

From pchilanomate at openjdk.org  Tue Oct 29 22:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v18]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <0oRznkXzZMzer7mrnFTMa2iQhQA8CtBqez5UQKv1LnY=.19c17526-c482-4ac2-b72e-a3a02749a395@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add comments for Dean + move reload result_handler in generate_native_entry
 - add assert in ThawBase::recurse_thaw_interpreted_frame

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/3e8b4fe6..0f3b9021

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=16-17

  Stats: 15 lines in 6 files changed: 10 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Oct 29 22:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
Message-ID: <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>

On Tue, 29 Oct 2024 01:59:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:
> 
>> 1349:   // set result handler
>> 1350:   __ mov(result_handler, r0);
>> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));
> 
> I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

Added comment.

> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:
> 
>> 1507:     Label no_oop;
>> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
>> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));
> 
> We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

Moved.

> src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:
> 
>> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
>> 642: #ifdef _LP64
>> 643:   return r15_off / 2;
> 
> I think using r15_offset_in_bytes() would be less confusing.

I copied the same comments the other platforms have to make it more clear.

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
> 
>> 357:   push_cont_fastpath();
>> 358: 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 
> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

> src/hotspot/share/c1/c1_Runtime1.hpp line 138:
> 
>> 136:   static void initialize_pd();
>> 137: 
>> 138:   static uint runtime_blob_current_thread_offset(frame f);
> 
> I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591515
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593810
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821592920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930

From pchilanomate at openjdk.org  Tue Oct 29 22:19:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <Nkpsk98F1YL5lu1qiEX-gV4L_dM2PEr6SuZsjzjGQTo=.02a5f470-a732-4e89-ae53-0747648811d1@github.com>
Message-ID: <zhJLtXdHx6wG6RjM643rdNM2ddMbk06Arw1B2CsUQ2k=.1585d596-6a33-4d8f-9b34-8a792736a4fb@github.com>

On Mon, 28 Oct 2024 21:07:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore use of atPointA in test StopThreadTest.java
>>  - remove interruptible check from conditional in Object::wait
>
> src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:
> 
>> 144:   // Make sure that locals is already relativized.
>> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
>> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)
> 
> What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

It's for the 2 extra words for native methods (temp oop/result handler). Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591143

From pchilanomate at openjdk.org  Tue Oct 29 22:19:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
Message-ID: <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>

On Tue, 29 Oct 2024 20:39:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment in SharedRuntime::generate_native_wrapper
>
> src/hotspot/share/code/nmethod.cpp line 712:
> 
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
>> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

I added a comment already in `vthread_monitor_waited_event()` in ObjectMonitor.cpp. I think it's better placed there.

> src/hotspot/share/code/nmethod.cpp line 1302:
> 
>> 1300:     _compiler_type           = type;
>> 1301:     _orig_pc_offset          = 0;
>> 1302:     _num_stack_arg_slots     = 0;
> 
> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264

From dlong at openjdk.org  Tue Oct 29 22:19:22 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:19:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <v4Y7AuP0UB6uU5ayYuBsziKB-Zac8Aj0LJ-me8nI9Qo=.ebce824f-37e5-4864-b75b-f5f9604474b3@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnv.cpp line 1363:

> 1361:   }
> 1362: 
> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {

Do we need to check for `java_thread == nullptr` for other locking modes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124

From dlong at openjdk.org  Tue Oct 29 22:26:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:26:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <taG8411IReqDKGmD3YXSdAX4iiPoUTixbnHUQNA0sOM=.10e86e63-bd4f-4890-bfe8-51e58a692402@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:

> 1600:           // If the thread was found on the ObjectWaiter list, then
> 1601:           // it has not been notified.
> 1602:           Handle th(current_thread, w->threadObj());

Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480

From ascarpino at openjdk.org  Tue Oct 29 22:32:17 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Tue, 29 Oct 2024 22:32:17 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v4]
In-Reply-To: <jRKGV3_VgkBoy-UkFHqeoOSqu_O3oQ28ZaGVeZqb2Os=.20615bcf-40d2-4541-b5db-69b4df5f3efe@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <jRKGV3_VgkBoy-UkFHqeoOSqu_O3oQ28ZaGVeZqb2Os=.20615bcf-40d2-4541-b5db-69b4df5f3efe@github.com>
Message-ID: <_4VWI-IRI9MxWfkvO3IqqD8jtR5xuLE59qvH34stZ6k=.b8f68710-dbb3-4ac0-b86f-ae045d7bb550@github.com>

On Fri, 25 Oct 2024 17:15:34 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - removed a couple instances of provider property
>  - Merge branch 'master' into jce-provider-prop
>  - fixed whitespace
>  - Updated a few more tests.
>  - 8341927: Remove hardcoded SunJCE provider

Marked as reviewed by ascarpino (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21551#pullrequestreview-2403191902

From dlong at openjdk.org  Tue Oct 29 22:49:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:49:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <iJbJpOi1IJf3dZ-d0n8z0a1HC97wsFvR8kgXvOnO-PA=.7a2f27b4-ffa4-4112-acd7-055fd16fcd3b@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.toPreemptStatus() in Continuation.java

I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785

From dlong at openjdk.org  Tue Oct 29 22:55:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 22:55:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <Iy8BxuaNQ1xnGaF-KmfsxnKdkV7mCMlkIBgdoPRiONU=.291a33a1-160d-4579-ba2b-795465d4d37e@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationEntry.cpp line 51:

> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;

I don't see why we need these relative offsets.  Instead of doing

_thaw_call_pc_offset = __ pc() - start;

why not do

_thaw_call_pc = __ pc();

The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432

From dlong at openjdk.org  Tue Oct 29 23:01:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:01:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:

> 314:     pc = ContinuationHelper::return_address_at(
> 315:            sp - frame::sender_sp_ret_address_offset());
> 316:   }

You could do this with an overload instead:

static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) {
  assert(pc != nullptr, "");
  [...]
}
static void set_anchor(JavaThread* thread, intptr_t* sp) {
  address pc = ContinuationHelper::return_address_at(
    sp - frame::sender_sp_ret_address_offset());
  set_anchor(thread, sp, pc);
}

but the compiler probably optmizes the above check just fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036

From dlong at openjdk.org  Tue Oct 29 23:08:28 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:08:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:

> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;

`cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152

From dlong at openjdk.org  Tue Oct 29 23:15:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:15:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <i04QzOl9bIYXpYJGAD7n61f8kRdEtp2FR55sLcK4oUc=.da12b6ff-0527-4b08-a171-fa5e6af37d37@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:

> 1061:   unwind_frames();
> 1062: 
> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);

It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581

From dlong at openjdk.org  Tue Oct 29 23:19:27 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:19:27 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:

> 1409:     // zero out fields (but not the stack)
> 1410:     const size_t hs = oopDesc::header_size();
> 1411:     oopDesc::set_klass_gap(mem, 0);

Why, bug fix or cleanup?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040

From dlong at openjdk.org  Tue Oct 29 23:23:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:23:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <KDT7bMjVw0N91OMe8OaAdjS2obawYpv6VkNO8vLUhMY=.dc5d87b7-7000-4477-9200-83cf14df8f15@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659:

> 1657:   int i = 0;
> 1658:   for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) {
> 1659:     if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) {

OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194

From dlong at openjdk.org  Tue Oct 29 23:27:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:27:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <XJWMMcQer9q8ZFBxU-TrPlXOu7rG3fnEabQIpavaWok=.abf4c6b4-d28f-4c49-a2ad-5b02fee39f33@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:

> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)

So this means it's OK to over-estimate the size here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267

From dlong at openjdk.org  Tue Oct 29 23:52:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Tue, 29 Oct 2024 23:52:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <hbNGY5tBwNUnWHk1JH-5re8wRI8yPoSRzsVJy_y5pE8=.ea49eee0-45a6-42c2-84d1-5e8be3c257d5@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:

> 2060:   }
> 2061: 
> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);

Suggestion:

  f.next(SmallRegisterMap::instance(), true /* stop */);

This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778

From dlong at openjdk.org  Wed Oct 30 00:19:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:19:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
Message-ID: <FdLVhmsz11XwyK4LSofGiYbWLpD5hwuC8OKg4uSL0-A=.29d607fe-6e23-4722-9520-fa639fe93cfc@github.com>

On Tue, 29 Oct 2024 00:04:09 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment in VThreadWaitReenter

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:

> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
> 2649:   } else {
> 2650:     _stream.next(SmallRegisterMap::instance);

Suggestion:

    _stream.next(SmallRegisterMap::instance());

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316

From pchilanomate at openjdk.org  Wed Oct 30 00:44:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 00:44:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add klass_name check for is_object_wait0
 - Fix comment in continuation.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0f3b9021..9fd4c036

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=17-18

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 00:44:17 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 00:44:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <d3ebVapQLYjPsTXzMwb5KBNWGju_l01GpoktKFFwZaI=.e135c3c7-bb74-46ba-a9e5-95ffc780ee4b@github.com>
Message-ID: <cWO4-UKVH-sGiJQDYO3nmH0HBnP8daGHGxouNARu9P4=.91bbac48-3977-4a4a-90ac-27750b4e196b@github.com>

On Tue, 29 Oct 2024 21:32:44 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/oops/method.cpp line 870:
> 
>> 868: }
>> 869: 
>> 870: bool Method::is_object_wait0() const {
> 
> It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

Right, I added a check for the klass too.

> src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:
> 
>> 253:                          RegisterMap::WalkContinuation::include);
>> 254:     full_map.set_include_argument_oops(false);
>> 255:     closure->do_frame(f, map);
> 
> This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

The full map gets only populated once we get the sender. We only need it when processing the caller which needs to know where each register was spilled since it might contain an oop.

> src/hotspot/share/prims/jvmtiEnv.cpp line 1363:
> 
>> 1361:   }
>> 1362: 
>> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {
> 
> Do we need to check for `java_thread == nullptr` for other locking modes?

No, both LM_LIGHTWEIGHT and LM_MONITOR have support for virtual threads. LM_LEGACY doesn't, so if the virtual thread is unmounted we know there is no monitor information to collect.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:
> 
>> 1600:           // If the thread was found on the ObjectWaiter list, then
>> 1601:           // it has not been notified.
>> 1602:           Handle th(current_thread, w->threadObj());
> 
> Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

We already filtered virtual threads above so no point in calling get_vthread_or_thread_oop() again. They will actually return the same result though.

> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.toPreemptStatus() in Continuation.java
> 
> I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

Should be just PreemptStatus. Fixed.

> src/hotspot/share/runtime/continuationEntry.cpp line 51:
> 
>> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
>> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
>> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;
> 
> I don't see why we need these relative offsets.  Instead of doing
> 
> _thaw_call_pc_offset = __ pc() - start;
> 
> why not do
> 
> _thaw_call_pc = __ pc();
> 
> The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

But these are generated in a temporary buffer. Until we call nmethod::new_native_nmethod() we won't know the final addresses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695964
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821697629
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698318
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155

From dlong at openjdk.org  Wed Oct 30 00:55:29 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:55:29 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <kSyXqckzqwcYnwBAr1wmg3bMteP-BbspPcYbT8nIdrI=.a9198448-145d-468b-9ee7-c6032215d689@github.com>
 <A8evX7NnTrxUXTYbIDNmkGd_Uso1gQ375xOO648EE3U=.3a3513fb-9518-4ec0-ab2a-e85876c776fb@github.com>
Message-ID: <PTE67iiSpLLs5DWzn4rJE6FjIZyA-4G_i-xUdJdLIrE=.744a6de2-625e-491b-a3f6-14bc17a2e168@github.com>

On Tue, 29 Oct 2024 22:12:56 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
>> 
>>> 357:   push_cont_fastpath();
>>> 358: 
>>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 
>> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.
>
> Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

OK, I was looking for where it stores it in the anchor, but it doesn't, at least not until make_walkable() is called.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135

From dlong at openjdk.org  Wed Oct 30 00:55:30 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 00:55:30 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:

> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 360:   lea(rscratch1, resume_pc);
> 361:   push(rscratch1);

Suggestion:

  push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030

From dlong at openjdk.org  Wed Oct 30 01:55:23 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 01:55:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.PreemptStatus() in Continuation.java

As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421

From dlong at openjdk.org  Wed Oct 30 02:09:24 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 02:09:24 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <v_0xCKqgq9wJzy9ttitKZgC87K6GagkmPa6EOhdu1Ec=.637a00ad-7be5-485f-b44d-9858389cfec7@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:

> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
> 2045:     // frame effectively overwritting the restored registers during that call.

Suggestion:

    // frame effectively overwriting the restored registers during that call.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997

From lmao at openjdk.org  Wed Oct 30 02:12:22 2024
From: lmao at openjdk.org (Liang Mao)
Date: Wed, 30 Oct 2024 02:12:22 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <ABXS9VGZgO5rYX2O_cjToFf5Mv1kDSia2hMvA95BbGM=.01ddfdca-38e4-4440-b677-811a2f9c6805@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
 <ABXS9VGZgO5rYX2O_cjToFf5Mv1kDSia2hMvA95BbGM=.01ddfdca-38e4-4440-b677-811a2f9c6805@github.com>
Message-ID: <L8N4NbS_URQkt0cLY8s3UajQEFoL1L_fg25K4pntzS0=.fa6cbb88-e95d-4f81-ac04-2a9b1174a5ac@github.com>

On Tue, 22 Oct 2024 18:25:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits:
>> 
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - Merge
>>  - 8342560: GenShen: Fix confusing method name
>>    
>>    Reviewed-by: ysr
>>  - 8342564: GenShen: Only reference young/old generation names in generational mode
>>    
>>    Reviewed-by: xpeng, ysr
>>  - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux
>>  - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux
>>  - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
>>    
>>    Reviewed-by: kdnilsen, ysr
>>  - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit
>>    
>>    Reviewed-by: ysr
>>  - 8342278: GenShen: Move non-generational mode test out of generational test configuration
>>    
>>    Reviewed-by: ysr
>>  - 8342255: GenShen: Remove unnecessary enum initial values
>>    
>>    Reviewed-by: ysr
>>  - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408
>
> We disabled tiered compilation to force everything to compile through C2 to get more consistent results.

@earthling-amzn ?thanks for providing your options. Looks like disabling pacing would help the score. 

-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC

I guess 4 cores may not be a target configuration for pauseless GC since generational pauseless GC requires at least 2 concurrent GC threads that already occupy half of CPU resource. I did a rough test on 8 cores and 16 cores according to your options. GenShen doesn't have obvious advantages with 8 cores and Shenandoah seems to outperform genshen significantly with 16 cores. Would you please help verify the result in your environment?

8 cores -Xmx8g -Xms8g:

GenShen:
RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 8098, critical-jOPS = 6132
RUN RESULT: hbIR (max attempted) = 8944, hbIR (settled) = 8574, max-jOPS = 7781, critical-jOPS = 6130

Shenandoah:
RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 7616, critical-jOPS = 6194
RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 7712, critical-jOPS = 6262

16 cores -Xmx20g -Xms20g:

GenShen:
RUN RESULT: hbIR (max attempted) = 19881, hbIR (settled) = 16584, max-jOPS = 17694, critical-jOPS = 13274
RUN RESULT: hbIR (max attempted) = 19881, hbIR (settled) = 18724, max-jOPS = 17694, critical-jOPS = 13445
Shenandoah:
RUN RESULT: hbIR (max attempted) = 23838, hbIR (settled) = 20446, max-jOPS = 18594, critical-jOPS = 15441
RUN RESULT: hbIR (max attempted) = 20138, hbIR (settled) = 19989, max-jOPS = 18728, critical-jOPS = 14967

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2445672323

From dholmes at openjdk.org  Wed Oct 30 02:21:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 02:21:11 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
Message-ID: <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>

On Tue, 29 Oct 2024 15:30:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 55:
>> 
>>> 53: #error unsupported platform
>>> 54: #endif
>>> 55: 
>> 
>> Does Windows Aarch64 define _LP64?
>
> Yes. As Julian says, it's something we set up in our builds:
> 
>   if test "x$FLAGS_CPU_BITS" = x64; then
>     $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
>     $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
>   fi

Ugghh! I was thrown by the `x` in test expressions and thought `x64` meant, well, x64 :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821763177

From dholmes at openjdk.org  Wed Oct 30 02:27:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 02:27:13 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

Hotspot updates look good.

src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 382:

> 380:                  i, xmm[1], xmm[0]);
> 381:   }
> 382:   st->print("  MXCSR=" UINT32_FORMAT_X_0, uc->MxCsr);

Is this moved from somewhere else?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2403423258
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821766707

From kbarrett at openjdk.org  Wed Oct 30 03:44:23 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Oct 2024 03:44:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

I didn't spend much time looking for more places that could use updating.  We can
always do more cleaning up later if more are found.

make/scripts/compare.sh line 79:

> 77: 
> 78: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
> 79:   DIS_DIFF_FILTER="$SED -r \

This is now being defined for windows-aarch64 too, when it previously wasn't.  Is that intentional?

make/scripts/compare.sh line 1457:

> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"

This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
given the "x64" suffix.

src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1433:

> 1431:   // instructions that are SP relative. After the jni call we switch to FP
> 1432:   // relative instructions instead of re-adjusting the stack on windows.
> 1433:   // ****************************************************************************

I think it might be better to keep this comment.  It might be helpful information for someone who
needs to touch this code between now and when we remove all 32bit x86 support (which might
be soonish, but not immediate).  And this comment will go away when that change happens.

src/hotspot/os/windows/os_windows.cpp line 2592:

> 2590:   ctx->Rdx = (DWORD)0;             // remainder
> 2591:   // Continue the execution
> 2592: #else

Maybe retain `#else` clause as an `#error`?

src/hotspot/share/adlc/main.cpp line 494:

> 492: }
> 493: 
> 494: #if !defined(_WIN32) || defined(_WIN64)

Removing the conditionalization is fine for this change.  But see also 
https://bugs.openjdk.org/browse/JDK-8342639
I've added a note there that this change removed the conditionalization.

src/java.base/windows/native/libjava/gdefs_md.h line 31:

> 29: 
> 30: #include <stddef.h>
> 31: #ifndef _WIN64

I suspect the unix/windows gdefs_md.h files could be eliminated, and just make gdefs.h use portable
headers.  That can be done as a separate cleanup.

src/java.base/windows/native/libjava/jlong_md.h line 66:

> 64: #define jlong_zero_init ((jlong) 0)
> 65: 
> 66: #ifdef _WIN64

After this change I think the differences between the unix and windows variants of this file are trivial
and could be resolved in favor of moving everything directly into jlong.h.  Though note there are some
places in java.desktop that currently directly include jlong_md.h.  This can be done as a separate cleanup.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2403283976
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821670031
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821671116
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821680493
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821684248
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821796117
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821806395
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821809957

From kbarrett at openjdk.org  Wed Oct 30 03:44:24 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 30 Oct 2024 03:44:24 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
Message-ID: <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>

On Tue, 29 Oct 2024 09:51:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 381:
>> 
>>> 379:   {
>>> 380: #undef CSIZE
>>> 381: #if defined(_LP64)
>> 
>> Windows is actually LLP64 programming model not LP64. Does Windows x64 define _LP64 or is that something we do in our build?
>
> It's something we do in our build. For us, _LP64 really means 64 bit

It seems like the `_WIN64` check here was never useful.  It's also been there since before the
mercurial age.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1821799991

From jwaters at openjdk.org  Wed Oct 30 05:31:12 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Oct 2024 05:31:12 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v3]
In-Reply-To: <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
Message-ID: <eNY1Wjj9xSFc1ZBbMzdeKYfQb2a8-4HsBCpHEo9TeVo=.75d919f0-2300-4820-85a0-3ac9a59af4e7@github.com>

On Sun, 27 Oct 2024 06:25:02 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into unused
>  - 8342682

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2445894205

From cjplummer at openjdk.org  Wed Oct 30 06:30:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 30 Oct 2024 06:30:09 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v3]
In-Reply-To: <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
Message-ID: <aA_T7_v8bpkOiXMGJqGoUZwpGuh9c4Yerz2eTzHyhqw=.d011b331-9f69-4429-9991-53d7116892c5@github.com>

On Sun, 27 Oct 2024 06:25:02 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into unused
>  - 8342682

src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 40:

> 38:  */
> 39: 
> 40: // static HANDLE memHandle = NULL;

I still think this should be removed instead of commented out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1821961354

From sspitsyn at openjdk.org  Wed Oct 30 06:38:04 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Oct 2024 06:38:04 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation
In-Reply-To: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
Message-ID: <BxhVJg8gcLXuWNQX_T6R40R4bQ6fBnq2UyK2fOlIBbA=.75b956fd-9796-47fc-b9ec-514b209e9927@github.com>

On Mon, 28 Oct 2024 08:34:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
> 
> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
> 
> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
> 
> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

The fix looks good to me. It is important and nice simplification.
The JVMTI part is strait forward.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21735#pullrequestreview-2403758889

From sundar at openjdk.org  Wed Oct 30 07:38:48 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Wed, 30 Oct 2024 07:38:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
Message-ID: <KpTjC3N9OKmhZehKUPHo3hDuxCaNLC2rP9VYkWvCDIo=.d2ad268f-39af-4b60-9fc1-f6546a85f7ed@github.com>

On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Update copyrights. Remove @compile line form Marshal.java test.
>  - Update copyright headers
>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>  - Merge branch 'master' into jep486
>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>  - remove privileged calls in logging/File* tests
>  - delete PermissionTest.java as it simply constructs provider impls
>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>    Removed createPrivateValue(), no longer used.
>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839

I reviewed jdk.dynalink changes. LGTM

-------------

Marked as reviewed by sundar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2403864492

From sspitsyn at openjdk.org  Wed Oct 30 09:48:26 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 30 Oct 2024 09:48:26 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/runtime/continuation.cpp line 88:

> 86:       if (_target->has_async_exception_condition()) {
> 87:         _failed = true;
> 88:       }

Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

src/hotspot/share/runtime/continuation.cpp line 115:

> 113:       if (jvmti_present) {
> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
> 115:         if (JvmtiExport::should_post_vthread_mount()) {

This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512

From ihse at openjdk.org  Wed Oct 30 10:29:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 10:29:09 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <sAJXZbzuAgQjvXF6DwSVLLnjZOHWd_Oeyc-CYianFBM=.de4bbf61-44b3-4616-acdf-4039e1b9ad99@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21401#pullrequestreview-2404324088

From ihse at openjdk.org  Wed Oct 30 10:45:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 10:45:15 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <_qzgBDOylXHxj0SYcBZzUHj-vAiULv6KJnkgmIXD3W0=.e9dbd148-cc69-4f69-bb1e-c87678aa5d52@github.com>
Message-ID: <HtcDnWKURWPMw0ukH8HXBHIfisML2RUl_Md5_8EBRXY=.c3cec63e-ca03-4078-b4ed-b1b5682266ee@github.com>

On Wed, 30 Oct 2024 02:23:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp line 382:
> 
>> 380:                  i, xmm[1], xmm[0]);
>> 381:   }
>> 382:   st->print("  MXCSR=" UINT32_FORMAT_X_0, uc->MxCsr);
> 
> Is this moved from somewhere else?

No, it was added in `master`. You are looking at a merge commit. (I usually don't merge in master in an ongoing PR but in this case there was a conflict so I had to resolve it.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822345558

From ihse at openjdk.org  Wed Oct 30 10:45:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 10:45:16 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <47vWGZFVljdoUM4qtxeVZTqNGFtRWVuoiIkg3fuc3UA=.58a1c6f6-e32b-4424-93a0-b1e7001f5e3c@github.com>
 <xkaDpkMvx9DwZVzuPapJtXEwaJSExoG5oVys-7onylA=.3441f52d-ec73-431b-b123-c4db6be55dda@github.com>
Message-ID: <eOYIXtGbSZdwTEG2t93ICRJPWWDltpJfW7h_H-QBGGU=.29a2b636-99ab-4ef1-9770-aacec2e0158d@github.com>

On Wed, 30 Oct 2024 02:18:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes. As Julian says, it's something we set up in our builds:
>> 
>>   if test "x$FLAGS_CPU_BITS" = x64; then
>>     $1_DEFINES_CPU_JDK="${$1_DEFINES_CPU_JDK} -D_LP64=1"
>>     $1_DEFINES_CPU_JVM="${$1_DEFINES_CPU_JVM} -D_LP64=1"
>>   fi
>
> Ugghh! I was thrown by the `x` in test expressions and thought `x64` meant, well, x64 :)

Yeah, that idiom is indeed difficult to read. :-(

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822342078

From aboldtch at openjdk.org  Wed Oct 30 11:08:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Oct 2024 11:08:15 GMT
Subject: Integrated: 8341692: Implement JEP 490: ZGC: Remove the
 Non-Generational Mode
In-Reply-To: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
Message-ID: <FVw-VY4CzoOIAX6tfPzAstzHWQuZvpSrIWq8cehJKTo=.94806ea3-7104-4061-b0a5-df0c12061e03@github.com>

On Tue, 8 Oct 2024 07:20:49 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)

This pull request has now been integrated.

Changeset: 821c514a
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/821c514a132e809a14648ddbb56f2ffee85fd35a
Stats:     39435 lines in 407 files changed: 155 ins; 39010 del; 270 mod

8341692: Implement JEP 490: ZGC: Remove the Non-Generational Mode

Reviewed-by: ihse, eosterlund, stefank, prr, cjplummer, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21401

From ihse at openjdk.org  Wed Oct 30 11:08:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:08:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>

On Tue, 29 Oct 2024 23:48:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> make/scripts/compare.sh line 79:
> 
>> 77: 
>> 78: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>> 79:   DIS_DIFF_FILTER="$SED -r \
> 
> This is now being defined for windows-aarch64 too, when it previously wasn't.  Is that intentional?

No, it was not intentional, as in I forgot about the aarch64 version of Windows.

With that said, I think it still might make sense to keep it this way. I don't think anyone has ever tried running the compare script on windows-aarch64; if they had, the lack of a filter at all would have made it basically unusable. This pattern is trying to hide 64-bit hex strings, and it is reasonable to assume it will work for aarch64 as well. If it doesn't, then its better to use this as a starting point for tweaking. Good catch, though!

> make/scripts/compare.sh line 1457:
> 
>> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
> 
> This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
> given the "x64" suffix.

Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. 

I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822382796
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822386222

From aboldtch at openjdk.org  Wed Oct 30 11:08:14 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 30 Oct 2024 11:08:14 GMT
Subject: RFR: 8341692: Implement JEP 490: ZGC: Remove the Non-Generational
 Mode [v5]
In-Reply-To: <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
References: <8f9QplKu0Rm5E0mw08AOKygdGEBnUtBlTiEZV8N8pgQ=.081af70d-9b69-429f-b0b1-7914c935c893@github.com>
 <uprL_mD0ITSvSNIkISnGOW4fTxLA0puvexC45j4-Rxs=.91d6b3ad-eec3-40ec-960c-8d2ba816d61b@github.com>
Message-ID: <-eb6Uf9dOazfISAdwMswOX5EXfv3XclZ61zEHZzcyzI=.b0c8c543-54af-44ba-b059-9fea2d26dc57@github.com>

On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational Mode`. See the JEP for details. [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Remove GCName::Z
>  - Merge tag 'jdk-24+21' into JDK-8341692
>    
>    Added tag jdk-24+21 for changeset 8bcd4920
>  - Merge tag 'jdk-24+20' into JDK-8341692
>    
>    Added tag jdk-24+20 for changeset 7a64fbbb
>  - Merge tag 'jdk-24+19' into JDK-8341692
>    
>    Added tag jdk-24+19 for changeset e7c5bf45
>  - LargeWindowPaintTest.java fix id typo
>  - Fix problem-listed @requires typo
>  - Fix @requires !vm.gc.Z, must use vm.gc != "Z"
>  - Reorder z_globals options: product > diagnostic product > develop
>  - Consistent albite special code style
>  - Consistent order between ZArguments and GCArguments
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/8bcd4920...eef214b4

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21401#issuecomment-2446615222

From ihse at openjdk.org  Wed Oct 30 11:13:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:13:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v14]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <KvUQC6EJEWrUs-hTd1RUv54Tks7naEdUavPtMPlqNJM=.b2c52593-7ccd-4de0-b508-2086aed554cf@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore comment on calling conventions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/3556bec5..341de0b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=12-13

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Wed Oct 30 11:13:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:13:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v12]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <xM8E_uqyfL5bpnC-q9WX2ddV61gdjiRvMAIIX1ssgCo=.26e776dc-85ef-4594-a916-55d22a06739b@github.com>

On Wed, 30 Oct 2024 00:07:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adlc need _CRT_NONSTDC_NO_WARNINGS as well... *sigh*
>
> src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1433:
> 
>> 1431: 
>> 1432:   int stack_size = stack_slots * VMRegImpl::stack_slot_size;
>> 1433: 
> 
> I think it might be better to keep this comment.  It might be helpful information for someone who
> needs to touch this code between now and when we remove all 32bit x86 support (which might
> be soonish, but not immediate).  And this comment will go away when that change happens.

Ok. 

Many of these changes were made in the jdk-sandbox before the JEP to deprecate all 32-bit x86 code was created, and in that perspective, it made more sense to actually properly clean out the Windows things from the x86 code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822396126

From ihse at openjdk.org  Wed Oct 30 11:18:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:18:27 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Error in os_windows.cpp for unknown cpu

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/341de0b2..0fff0971

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=13-14

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Wed Oct 30 11:23:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:23:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>

On Wed, 30 Oct 2024 03:05:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Error in os_windows.cpp for unknown cpu
>
> src/hotspot/share/adlc/main.cpp line 494:
> 
>> 492: }
>> 493: 
>> 494: #if !defined(_WIN32) || defined(_WIN64)
> 
> Removing the conditionalization is fine for this change.  But see also 
> https://bugs.openjdk.org/browse/JDK-8342639
> I've added a note there that this change removed the conditionalization.

I'm glad you're giving some TLC to adlc. It is in desperate need of it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822410201

From ihse at openjdk.org  Wed Oct 30 11:23:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:23:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <S9Gx8J0gfrPdVOdRYv4b4f9WZORPs1j5hldZ5RCCuGA=.f7654d5f-11d7-43ae-b1ca-608bb10fed11@github.com>
 <ypss4c8pglisaghlJS8u7RlfpEH7tLztp43SWy9MaOA=.d099dab2-683b-4999-9f4a-d1c375bd8a37@github.com>
 <mwLADD0jOIritoTWWvgAbFlER-xpyQRnOvmQJhXHE2I=.7c5a4220-f50c-4dfc-a874-7ab6c0d7fd34@github.com>
Message-ID: <tF_hM8P2ePWwvhpQtU4hQxAQsIRAQiBckplGKAoniXI=.c5767e49-0861-4615-8562-168800258573@github.com>

On Wed, 30 Oct 2024 03:13:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It's something we do in our build. For us, _LP64 really means 64 bit
>
> It seems like the `_WIN64` check here was never useful.  It's also been there since before the
> mercurial age.

The "mercurial age". Sounds like something in-between the stone age and the bronze age. :-D

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822412706

From ihse at openjdk.org  Wed Oct 30 11:31:17 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 11:31:17 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
Message-ID: <4vEbuSNfUF3Dvk1-qqvtbP8Xz73VvbYxA0uPO5b1Kuo=.01762c04-f070-4eb4-a059-6481c720e56c@github.com>

On Wed, 30 Oct 2024 03:24:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Error in os_windows.cpp for unknown cpu
>
> src/java.base/windows/native/libjava/gdefs_md.h line 31:
> 
>> 29: 
>> 30: #include <stddef.h>
>> 31: #ifndef _WIN64
> 
> I suspect the unix/windows gdefs_md.h files could be eliminated, and just make gdefs.h use portable
> headers.  That can be done as a separate cleanup.

Good point. I created https://bugs.openjdk.org/browse/JDK-8343291.

> src/java.base/windows/native/libjava/jlong_md.h line 66:
> 
>> 64: #define jlong_zero_init ((jlong) 0)
>> 65: 
>> 66: #ifdef _WIN64
> 
> After this change I think the differences between the unix and windows variants of this file are trivial
> and could be resolved in favor of moving everything directly into jlong.h.  Though note there are some
> places in java.desktop that currently directly include jlong_md.h.  This can be done as a separate cleanup.

Right. I updated JDK-8343291 to cover this case as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822420044
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822422712

From shade at openjdk.org  Wed Oct 30 12:14:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 12:14:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
Message-ID: <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>

On Tue, 29 Oct 2024 20:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c

I am basically okay with this PR. Only a few leftover comments.

make/hotspot/gensrc/GensrcAdlc.gmk line 50:

> 48:     ADLC_CFLAGS := -nologo -EHsc
> 49:     ADLC_CFLAGS_WARNINGS := -W3 -D_CRT_SECURE_NO_WARNINGS \
> 50:          -D_CRT_DECLARE_NONSTDC_NAMES -D_CRT_NONSTDC_NO_WARNINGS

Not clear why do we need these new warnings? I don't right away see anything in ADLC that needs it.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2404648390
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822494914

From shade at openjdk.org  Wed Oct 30 12:14:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 30 Oct 2024 12:14:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
Message-ID: <zBuS5aHaQ4o7a7N3Bb0uP9VdMjtR2Ud9ZxpPZpr2JSs=.69a88e5b-a23a-40ef-b6f3-7e24940b8f7b@github.com>

On Wed, 30 Oct 2024 11:05:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/scripts/compare.sh line 1457:
>> 
>>> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>>> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>>> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
>> 
>> This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
>> given the "x64" suffix.
>
> Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. 
> 
> I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...).

So then previously we would go for `jgss-windows-i586-bin.zip` on Windows/AArch64, which also does not seem good. Seeing how there are no bug reports about this, I think we are fine with doing this cleanup, and dealing with the bug, if any, later. @magicus, please submit a JBS issue for it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822489074

From jwaters at openjdk.org  Wed Oct 30 12:33:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 30 Oct 2024 12:33:28 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
Message-ID: <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>

On Wed, 30 Oct 2024 11:19:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/share/adlc/main.cpp line 494:
>> 
>>> 492: }
>>> 493: 
>>> 494: #if !defined(_WIN32) || defined(_WIN64)
>> 
>> Removing the conditionalization is fine for this change.  But see also 
>> https://bugs.openjdk.org/browse/JDK-8342639
>> I've added a note there that this change removed the conditionalization.
>
> I'm glad you're giving some TLC to adlc. It is in desperate need of it.

TLC?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822524730

From jsjolen at openjdk.org  Wed Oct 30 12:35:15 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 30 Oct 2024 12:35:15 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v3]
In-Reply-To: <nJ4LiRNuDCDyM90pRza3TcFJqhQpCiQ9vQM5sCsAgbU=.ee83f281-515a-4c91-8141-9b97d2fa644b@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <koGbJXx8AHRe7JYU8XqdYZ62smVyl9Zx3q9LacbJ2cA=.1df3cb40-7010-48ce-bdaa-57d3196e6b6a@github.com>
 <ho6z6guVBsXJuzEINHj3mcPHYJ3mvZXXdOuGNwd7X4A=.53f69147-2cd9-4284-a6c4-88ee0c3ef76b@github.com>
 <JeVyBj_GWoYNddOcXArZoV4BsnLCuYzlcU31eZQ3O4Q=.b57e831f-901e-49d8-bdef-1975b52a75f1@github.com>
 <QR_hSMY54okAfzvB4gjrMq5yRLmDBGu8zduSfmi7UU0=.011fe31b-3cb7-436c-9bd3-76c6a41f781d@github.com>
 <o2cyEfK9lde_Wlj1cKkgO2U2ge_HGPAzr12B3Y8u0bc=.ce9d77d7-23c5-4c9f-b82a-5413c9bfb55f@github.com>
 <O94o_Hku2zwfE9kUYaKH87H2mXHhhqcmgrjZJgy_Ko8=.9e34d2c4-5d8f-4a58-8890-e94b5f562bff@github.com>
 <nJ4LiRNuDCDyM90pRza3TcFJqhQpCiQ9vQM5sCsAgbU=.ee83f281-515a-4c91-8141-9b97d2fa644b@github.com>
Message-ID: <Pgny1IzDNY8f6te1AIBrmtNCDBssob1H4JD5ZhFAFk0=.bbc8c20e-6760-4d6d-95aa-21179158c0a8@github.com>

On Wed, 18 Sep 2024 05:53:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi @roberttoyonaga 
>> 
>> (Pinging @afshin-zafari and @jdksjolen)
>> 
>> First off, it is good that you ran into this since it highlights a possible real deadlock. Both locks are quite coarse. I cannot think from the top of my head of a scenario where we hold the tty lock and need NMT locking, but would not bet money on it. E.g. I bet we call malloc under ttylock (if only as a side effect of calling functions that return resource area). Malloc does not need locking; but its brittle and small changes can cause deadlocks (e.g. folks were thinking about moving ResourceArea memory to mmap, which needs NMT locks for tracking).
>> 
>>> Hi @tstuefe, it looks like calling [`os::print_memory_mappings`](https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L3785) from the windows implementation of `os::pd_release_memory` is causing the rank conflict between `tty_lock` and `NMT_lock`. This is getting called from `os::release_memory` [**after** we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/os.cpp#L2185-L2189).
>>> 
>>> gtest `release_bad_ranges` --> `os::release_memory` and acquire `NMT_lock` --> `os::pd_release_memory` --> `os::print_memory_mappings` and acquire `tty_lock`
>>> 
>> 
>> Ah thank you. I think I added that printing ages ago. I should not have used tty. The immediate solution to get you going may be to just change this from tty to `fileStream fs(stderr);`
>> 
>>> Is there a reason we cast a wider net and lock from outside of NMT code in `os::release_memory`, `os::uncommit_memory`, and `os::unmap_memory`? By contrast, in other functions such as `os::commit_memory` and `os::reserve_memory` we lock inside of `MemTracker` instead. For example, `pd_release_memory` is protected by the NMT lock, but `pd_reserve_memory` is not. Is the lock meant to synchronize the actual memory operations as well as NMT recording in some cases? If not, then maybe it makes sense to delay and move the lock acquisition inside `MemTracker` for consistency and to reduce surface area for lock conflicts.
>> 
>> The problem is that both tty_lock and the NMT lock are quite coarse. I always maintained that tty_lock is too coarse - we have many places where there is a ttyLocker somewhere at the start of a printing function, then the function goes and prints tons of infos it *retrieves under lock protection*. The better way to solve this is to assemble the text outside of lock protection, then only do the printing...
>
>> Hi @tstuefe,
>> 
>> > Ah thank you. I think I added that printing ages ago. I should not have used tty. The immediate solution to get you going may be to just change this from tty to fileStream fs(stderr);
>> 
>> Thanks! I adopted your suggestion and replaced tty. The lock conflict is gone now.
>> 
>> > Ensuring that we feed NMT the tracking information in the order they happened. This is only relevant for mmap accounting, since only there do we need to track address ranges. For malloc accounting, we just increase/decrease counters, and there, the order of operations does not matter, just that we do it atomically.
>> > ...
>> > A pragmatic solution would be to move the locking down the stack. Currently, we lock in the generic layer around { pd_release_memory() + MemTracker::record }. But we only need to lock around the OS allocation function (mmap/munmap/VirtualAlloc etc). So we could move the locks downward to the OS specific layer where the actual allocations happen in the OS code, e.g. just lock around { munmap() + MemTracker::record }.
>> 
>> Ok I see. So the locking should indeed not happen inside of `MemTracker`. Yes, maybe moving the locking down the stack into platform specific code would be a good task for the future. However, if the intention is to feed NMT the tracking info in the order it happened, why are the operations on memory in `os::commit_memory` and `os::reserve_memory` not protected by the lock? In those, we delay and lock inside `MemTracker` instead.
> 
> That looks like an error that should be fixed.

Hi @tstuefe, @roberttoyonaga 

We saw some test failures in non-generational ZGC due to this change. That GC is removed now, so there's no worry there. I did however look at all of our remaining usages of `ThreadCritical` and saw that there are thrre left that are related to NMT:


src/hotspot/share/nmt/nmtUsage.cpp
56     ThreadCritical tc;

src/hotspot/share/nmt/mallocTracker.cpp
65     // Use ThreadCritical to make sure that mtChunks don't get deallocated while the
68     ThreadCritical tc;


src/hotspot/share/memory/arena.cpp
178      ThreadCritical tc;  // Free chunks under TC lock so that NMT adjustment is stable.


I am not that familiar with this code. Is leaving these as they are intentional, or have we introduced a potential bug?

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2446981854

From mdonovan at openjdk.org  Wed Oct 30 13:09:26 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 30 Oct 2024 13:09:26 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v5]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <_oFqKyGhvDr_we8pXhQBkgryAnKRPK75sfHAUueGH0o=.910d8fd5-aeeb-4cbd-a987-c81522bd789c@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  added documentation for the new property

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/298670c6..3999bb84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=03-04

  Stats: 32 lines in 2 files changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From pchilanomate at openjdk.org  Wed Oct 30 13:28:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 13:28:04 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation
In-Reply-To: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
Message-ID: <GL1Ee-EpCnhzy-YlwhWnQSDTzya8mMnKi3vZhcxgXZg=.4c4c81a1-d208-4682-8f2a-f246b61e26f3@github.com>

On Mon, 28 Oct 2024 08:34:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
> 
> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
> 
> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
> 
> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

Looks good to me. Thanks for removing this.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21735#pullrequestreview-2404897854

From ihse at openjdk.org  Wed Oct 30 13:29:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 13:29:16 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <fmatb5I3zlShpkq5n-DLPj9V6DnHP7W7A9XZW-lMBio=.c1262400-6403-4d85-8f4a-9809ff7fe304@github.com>
 <T37Lzb10XcXKQ1iGKd9QS2qcERnBLTUeBG5FqzeuAr4=.cef44232-c775-48b7-8d86-b820f7dc77ca@github.com>
Message-ID: <l4vK22batFEVTwXl2Nwi4xqhAKWF2r_TMMIA8xUKYmE=.98fc0abf-1e13-44b1-b729-3bdba414de62@github.com>

On Wed, 30 Oct 2024 12:30:25 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I'm glad you're giving some TLC to adlc. It is in desperate need of it.
>
> TLC?

https://www.vocabulary.com/dictionary/TLC

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822628499

From ihse at openjdk.org  Wed Oct 30 13:37:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 30 Oct 2024 13:37:18 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <ypWvZ8Wj8IXPtjCO_VWR4iqIwzHMapAZhVIa71XCG9g=.c89f4e87-1eb5-4cd8-bfd5-1ef739b92f92@github.com>
Message-ID: <okuSQWnzbiRApfgxb9Ew56rztuYqWhzpMn3SAbnhDmE=.54c17b87-2b9a-466d-a3d4-10758c24dd33@github.com>

On Wed, 30 Oct 2024 12:11:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix 32/64-bit confusion in comment in VirtualMachineImpl.c
>
> make/hotspot/gensrc/GensrcAdlc.gmk line 50:
> 
>> 48:     ADLC_CFLAGS := -nologo -EHsc
>> 49:     ADLC_CFLAGS_WARNINGS := -W3 -D_CRT_SECURE_NO_WARNINGS \
>> 50:          -D_CRT_DECLARE_NONSTDC_NAMES -D_CRT_NONSTDC_NO_WARNINGS
> 
> Not clear why do we need these new warnings? I don't right away see anything in ADLC that needs it.

David Holmes [pointed out](https://github.com/openjdk/jdk/pull/21744#discussion_r1820429621) a chunk of old Windows definitions in `adlc.hpp`. I removed it, including the `_strdpup` define, to align with how the rest of Hotspot handles this peculiarity in Visual Studio, but that required adding the two special defines.

That change is arguably outside the scope of this PR. If you object to it, I can revert it and we'll handle that cleanup separately. It's sometimes hard to know where to stop when you start pulling on strings in old bad code and piece after piece of old legacy junk unravels.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1822651205

From duke at openjdk.org  Wed Oct 30 13:42:19 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 30 Oct 2024 13:42:19 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v3]
In-Reply-To: <Pgny1IzDNY8f6te1AIBrmtNCDBssob1H4JD5ZhFAFk0=.bbc8c20e-6760-4d6d-95aa-21179158c0a8@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <koGbJXx8AHRe7JYU8XqdYZ62smVyl9Zx3q9LacbJ2cA=.1df3cb40-7010-48ce-bdaa-57d3196e6b6a@github.com>
 <ho6z6guVBsXJuzEINHj3mcPHYJ3mvZXXdOuGNwd7X4A=.53f69147-2cd9-4284-a6c4-88ee0c3ef76b@github.com>
 <JeVyBj_GWoYNddOcXArZoV4BsnLCuYzlcU31eZQ3O4Q=.b57e831f-901e-49d8-bdef-1975b52a75f1@github.com>
 <QR_hSMY54okAfzvB4gjrMq5yRLmDBGu8zduSfmi7UU0=.011fe31b-3cb7-436c-9bd3-76c6a41f781d@github.com>
 <o2cyEfK9lde_Wlj1cKkgO2U2ge_HGPAzr12B3Y8u0bc=.ce9d77d7-23c5-4c9f-b82a-5413c9bfb55f@github.com>
 <O94o_Hku2zwfE9kUYaKH87H2mXHhhqcmgrjZJgy_Ko8=.9e34d2c4-5d8f-4a58-8890-e94b5f562bff@github.com>
 <nJ4LiRNuDCDyM90pRza3TcFJqhQpCiQ9vQM5sCsAgbU=.ee83f281-515a-4c91-8141-9b97d2fa644b@github.com>
 <Pgny1IzDNY8f6te1AIBrmtNCDBssob1H4JD5ZhFAFk0=.bbc8c20e-6760-4d6d-95aa-21179158c0a8@github.com>
Message-ID: <z5XfK1BvkDpUoq6cEcTXNFDqwXKGAhjCl3N8Jd8YLm0=.45728fd5-b544-490c-b407-958f4ed62688@github.com>

On Wed, 30 Oct 2024 12:32:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>>> Hi @tstuefe,
>>> 
>>> > Ah thank you. I think I added that printing ages ago. I should not have used tty. The immediate solution to get you going may be to just change this from tty to fileStream fs(stderr);
>>> 
>>> Thanks! I adopted your suggestion and replaced tty. The lock conflict is gone now.
>>> 
>>> > Ensuring that we feed NMT the tracking information in the order they happened. This is only relevant for mmap accounting, since only there do we need to track address ranges. For malloc accounting, we just increase/decrease counters, and there, the order of operations does not matter, just that we do it atomically.
>>> > ...
>>> > A pragmatic solution would be to move the locking down the stack. Currently, we lock in the generic layer around { pd_release_memory() + MemTracker::record }. But we only need to lock around the OS allocation function (mmap/munmap/VirtualAlloc etc). So we could move the locks downward to the OS specific layer where the actual allocations happen in the OS code, e.g. just lock around { munmap() + MemTracker::record }.
>>> 
>>> Ok I see. So the locking should indeed not happen inside of `MemTracker`. Yes, maybe moving the locking down the stack into platform specific code would be a good task for the future. However, if the intention is to feed NMT the tracking info in the order it happened, why are the operations on memory in `os::commit_memory` and `os::reserve_memory` not protected by the lock? In those, we delay and lock inside `MemTracker` instead.
>> 
>> That looks like an error that should be fixed.
>
> Hi @tstuefe, @roberttoyonaga 
> 
> We saw some test failures in non-generational ZGC due to this change. That GC is removed now, so there's no worry there. I did however look at all of our remaining usages of `ThreadCritical` and saw that there are thrre left that are related to NMT:
> 
> 
> src/hotspot/share/nmt/nmtUsage.cpp
> 56     ThreadCritical tc;
> 
> src/hotspot/share/nmt/mallocTracker.cpp
> 65     // Use ThreadCritical to make sure that mtChunks don't get deallocated while the
> 68     ThreadCritical tc;
> 
> 
> src/hotspot/share/memory/arena.cpp
> 178      ThreadCritical tc;  // Free chunks under TC lock so that NMT adjustment is stable.
> 
> 
> I am not that familiar with this code. Is leaving these as they are intentional, or have we introduced a potential bug?
> 
> Thank you.

Hi @jdksjolen, I originally replaced those instances, but then [put them back in](https://github.com/openjdk/jdk/pull/20852/commits/88e075d1023bbfa240c5606c9c64ea720a3e83d8) because I saw that they are related to chunks allocation/deallocation code where it seemed `ThreadCritical` was used for other reasons.  

I'm not certain, but looking at it again, it seems that the `ThreadCritical` uses in `ChunkPool::deallocate_chunk` and `ChunkPool::prune()` are only needed for NMT and are independent of the other `ThreadCritical` uses in that code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447196115

From duke at openjdk.org  Wed Oct 30 13:58:14 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 30 Oct 2024 13:58:14 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <O2bQ-h_pbfKEvpiKdBmvMq_oraIt34I4GvPMri7ybxc=.7a280e46-df5c-4e03-a95b-2cbfa037a710@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

Also, those uses of `ThreadCritical` are not protecting NMT's model of virtual memory. They are only protecting the reporting of malloc info specifically.  Although, it may still make sense to replace those instances with `NmtVirtualMemory_lock` since it's is still related to NMT.    

What do you think @tstuefe?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447247092

From mullan at openjdk.org  Wed Oct 30 14:18:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 14:18:09 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v5]
In-Reply-To: <_oFqKyGhvDr_we8pXhQBkgryAnKRPK75sfHAUueGH0o=.910d8fd5-aeeb-4cbd-a987-c81522bd789c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <_oFqKyGhvDr_we8pXhQBkgryAnKRPK75sfHAUueGH0o=.910d8fd5-aeeb-4cbd-a987-c81522bd789c@github.com>
Message-ID: <1Glo-jEMMPQR_wZGHMx5z3u1bqi1RS81B5S8pxtvyz0=.b051ea56-f619-44b4-9858-040a77077c29@github.com>

On Wed, 30 Oct 2024 13:09:26 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added documentation for the new property

Changes requested by mullan (Reviewer).

doc/testing.html line 596:

> 594: test/jdk/sun/security/pkcs11/README.</p>
> 595: <h3 id="testing-with-external-security-providers">Testing with external
> 596: security providers</h3>

Avoid the word "external". Change this to "Testing with an alternate security provider".

doc/testing.html line 597:

> 595: <h3 id="testing-with-external-security-providers">Testing with external
> 596: security providers</h3>
> 597: <p>Some security tests currently use a hardcoded provider for

Remove "currently".
s/for/when instantiating/
s/or SecretKeyFactory/or SecretKeyFactory objects/

doc/testing.html line 598:

> 596: security providers</h3>
> 597: <p>Some security tests currently use a hardcoded provider for
> 598: KeyFactory, Cipher, KeyPairGenerator, KeyGenerator, or SecretKeyFactory.

Put the APIs in code font.

doc/testing.html line 600:

> 598: KeyFactory, Cipher, KeyPairGenerator, KeyGenerator, or SecretKeyFactory.
> 599: Specify the <code>-Dtest.provider.name=NAME</code> property, to use a
> 600: specific provider when instantiating the service.</p>

s/specific/different/
No comma needed after "property".
s/service/service(s)/

doc/testing.md line 606:

> 604: test/jdk/sun/security/pkcs11/README.
> 605: 
> 606: ### Testing with external security providers

Same comments as above apply here.

doc/testing.md line 613:

> 611: instantiating the service.
> 612: 
> 613: ### Testing with external security providers

Duplicate entry?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21551#pullrequestreview-2405070747
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822724459
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822729868
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822732493
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822727408
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822732880
PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1822733645

From mdonovan at openjdk.org  Wed Oct 30 14:48:46 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 30 Oct 2024 14:48:46 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v6]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <TutLxRXjnc6TcdvvFuMXSgtR_YkWv57F5goFgDf0Ims=.d7e2ada9-fcc1-4bc7-be47-176c023d06e9@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  updated testing doc per PR comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/3999bb84..3889e339

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=04-05

  Stats: 30 lines in 2 files changed: 0 ins; 14 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From kevinw at openjdk.org  Wed Oct 30 14:49:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 30 Oct 2024 14:49:09 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v2]
In-Reply-To: <MyHTgmKnBXNjalisrxtPbLHBBp5Utt0Iol1bvZCGQ68=.2aa30838-7a26-4e48-b292-5494c449d5b0@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
 <eDf5F2pVFsjBTfFbBTqBcije9ELLo09mX92NuCP9w_Y=.d92b6c7a-0ef5-4d47-b768-e4874fbd6fc8@github.com>
 <RcTcJimK5umYqk4V96jQzVq2JRgfC-S0EmmBWmEz1t8=.e2fede71-677b-422c-a587-487ef417d8cc@github.com>
 <MyHTgmKnBXNjalisrxtPbLHBBp5Utt0Iol1bvZCGQ68=.2aa30838-7a26-4e48-b292-5494c449d5b0@github.com>
Message-ID: <RCAzCAEoHw_xDtty9gge92w5DiVPB3PXw2wF1aGXbfQ=.69e7e952-f1c9-429c-897a-9e885e3eb163@github.com>

On Tue, 29 Oct 2024 19:08:12 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 114:
>> 
>>> 112:                         String.format("Unable to open socket file %s: " +
>>> 113:                           "target process %d doesn't respond within %dms " +
>>> 114:                           "or HotSpot VM not loaded", socket_path, time_spend));
>> 
>> Do we still need a pid argument after this format string?
>> time_spent would read more easily than "spend" 8-) but we had have that for years.
>
> generally I dont think its a good idea to modify exception msgs ...

Agreed, this message is quite a famous "interface", it shouldn't change. I'm saying it looks like the pid parameter disappears as you move time_spend to the line above?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1822793215

From jsjolen at openjdk.org  Wed Oct 30 15:14:16 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 30 Oct 2024 15:14:16 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v3]
In-Reply-To: <z5XfK1BvkDpUoq6cEcTXNFDqwXKGAhjCl3N8Jd8YLm0=.45728fd5-b544-490c-b407-958f4ed62688@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <koGbJXx8AHRe7JYU8XqdYZ62smVyl9Zx3q9LacbJ2cA=.1df3cb40-7010-48ce-bdaa-57d3196e6b6a@github.com>
 <ho6z6guVBsXJuzEINHj3mcPHYJ3mvZXXdOuGNwd7X4A=.53f69147-2cd9-4284-a6c4-88ee0c3ef76b@github.com>
 <JeVyBj_GWoYNddOcXArZoV4BsnLCuYzlcU31eZQ3O4Q=.b57e831f-901e-49d8-bdef-1975b52a75f1@github.com>
 <QR_hSMY54okAfzvB4gjrMq5yRLmDBGu8zduSfmi7UU0=.011fe31b-3cb7-436c-9bd3-76c6a41f781d@github.com>
 <o2cyEfK9lde_Wlj1cKkgO2U2ge_HGPAzr12B3Y8u0bc=.ce9d77d7-23c5-4c9f-b82a-5413c9bfb55f@github.com>
 <O94o_Hku2zwfE9kUYaKH87H2mXHhhqcmgrjZJgy_Ko8=.9e34d2c4-5d8f-4a58-8890-e94b5f562bff@github.com>
 <nJ4LiRNuDCDyM90pRza3TcFJqhQpCiQ9vQM5sCsAgbU=.ee83f281-515a-4c91-8141-9b97d2fa644b@github.com>
 <Pgny1IzDNY8f6te1AIBrmtNCDBssob1H4JD5ZhFAFk0=.bbc8c20e-6760-4d6d-95aa-21179158c0a8@github.com>
 <z5XfK1BvkDpUoq6cEcTXNFDqwXKGAhjCl3N8Jd8YLm0=.45728fd5-b544-490c-b407-958f4ed62688@github.com>
Message-ID: <VWZsIUAZQmqJmflHV77Tq8mrIYAOq1PQRMQ0qRnRPWU=.6abcb336-2f33-4587-9787-d619a6a24133@github.com>

On Wed, 30 Oct 2024 13:39:00 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>I'm not certain, but looking at it again, it seems that the ThreadCritical uses in ChunkPool::deallocate_chunk and ChunkPool::prune() are only needed for NMT and are independent of the other ThreadCritical uses in that code.

At least for prune, that's needed for the chunk pool itself as it would otherwise be accessed concurrently.

>Also, those uses of ThreadCritical are not protecting NMT's model of virtual memory. They are only protecting the reporting of malloc info specifically. Although, it may still make sense to replace those instances with NmtVirtualMemory_lock since it's is still related to NMT.

OK, I understand. That seems reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447477881

From cjplummer at openjdk.org  Wed Oct 30 15:30:08 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 30 Oct 2024 15:30:08 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v3]
In-Reply-To: <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
 <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
Message-ID: <d53gngU6qyiIh-iGm-k_3gD_Ok3UFrq28YlNn-xZwdM=.62acd46f-dfe7-416f-8b63-690dda724dc3@github.com>

On Thu, 17 Oct 2024 16:12:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Man page update for jcmd.
>> 
>> Add updates for the filename options/arguments affected by:
>> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
>> 
>> Also:
>> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
>> 
>> In Description:
>> Each diagnostic command has its own set of options and arguments .
>>  
>> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
>> 
>> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VM.cds remove unnecessary text

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20401#pullrequestreview-2405341032

From stuefe at openjdk.org  Wed Oct 30 15:38:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Oct 2024 15:38:20 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <r4iAjCfPnFtNm5wqSBkLFXjkKq0D_lPJXehYNNfzvTE=.8d80f4ba-2fc6-45c5-8c3a-1c5aad23bdbc@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

We should get rid of this awful value correcting for arenas. I get headaches trying to think about this every time.

To remind everyone including me, some of the stuff is explained here:  [complex](https://bugs.openjdk.org/browse/JDK-8325890) . 

About locking around os::free - not sure if we can do this. Are all paths inside os::free lock free? It does call NMT. I think all cases inside NMT that touches are lock free, but am not sure. Have to think about this a biot.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447570321

From stuefe at openjdk.org  Wed Oct 30 15:47:14 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 30 Oct 2024 15:47:14 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <mFgLfBGCQBIW2Zi9alNdQNgO2Mf3fDW63haKQ3VCSL8=.aabd18f5-27fc-4ec2-b5ed-6e891e3e3ada@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

> About locking around os::free - not sure if we can do this. Are all paths inside os::free lock free? It does call NMT. I think all cases inside NMT that touches are lock free, but am not sure. Have to think about this a bit.

Ah okay should be fine. Both mallocs and frees should be lock free in NMT. In summary mode we just modify counters. In detail mode, we add to the malloc site table, but that one is lock free as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447593990

From rsunderbabu at openjdk.org  Wed Oct 30 15:48:34 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Wed, 30 Oct 2024 15:48:34 GMT
Subject: Integrated: 8202100: Merge vm/share/InMemoryJavaCompiler w/
 jdk/test/lib/compiler/InMemoryJavaCompiler
In-Reply-To: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
References: <Tev4XtxCPHHJ-T6iBQg9Bo8MRk4VUh8e6DTu1MjtRL8=.396fba21-e87c-4a8b-8097-e5e877a54b8e@github.com>
Message-ID: <WYcc9UPb-B6NKLXyZrnoOqYI6NE6bJVQptJkvidHdQA=.593c24b9-1782-425b-b999-3e66c580a3bf@github.com>

On Tue, 22 Oct 2024 15:52:27 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> Merging vm folder's InMemoryJavaCompiler into jdk folder's merge InMemoryJavaCompiler so that maintenance is easy.
> 
> Testing done for
> Tiers 1,2,3
> test/hotspot/jtreg tests

This pull request has now been integrated.

Changeset: 7404ddf2
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7404ddf24a162cff445cd0a26aec446461988bc8
Stats:     306 lines in 12 files changed: 108 ins; 164 del; 34 mod

8202100: Merge vm/share/InMemoryJavaCompiler w/ jdk/test/lib/compiler/InMemoryJavaCompiler

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/21641

From duke at openjdk.org  Wed Oct 30 16:01:30 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 30 Oct 2024 16:01:30 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <ZsvPkEmZCV0EtfP4DvSqXh06k0gufPDoVnQZalXM_9U=.cf9788dc-fa2e-4581-ba1d-53517f712504@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

Ok so there shouldn't be reentrancy if we use the `NmtVirtualMemory_lock` around `os::free`. But we also free in `ChunkPool::prune()` :

>> I'm not certain, but looking at it again, it seems that the ThreadCritical uses in ChunkPool::deallocate_chunk and ChunkPool::prune() are only needed for NMT and are independent of the other ThreadCritical uses in that code.

>At least for prune, that's needed for the chunk pool itself as it would otherwise be accessed concurrently.

So that means we'd need to have both `ThreadCritical` and `NmtVirtualMemory_lock` in that method (if we were to do the other replacements). One to protect the chunks and one to protect the malloc accounting.  It might also be good to rename `NmtVirtualMemory_lock` then too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2447631841

From rhalade at openjdk.org  Wed Oct 30 16:48:15 2024
From: rhalade at openjdk.org (Rajan Halade)
Date: Wed, 30 Oct 2024 16:48:15 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v6]
In-Reply-To: <TutLxRXjnc6TcdvvFuMXSgtR_YkWv57F5goFgDf0Ims=.d7e2ada9-fcc1-4bc7-be47-176c023d06e9@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <TutLxRXjnc6TcdvvFuMXSgtR_YkWv57F5goFgDf0Ims=.d7e2ada9-fcc1-4bc7-be47-176c023d06e9@github.com>
Message-ID: <FIPoqJT4qcCwW4om7t6Lfz_HCpN-1emYXmQaqHuUGT4=.c10add83-e40a-418c-9d50-503c77b63586@github.com>

On Wed, 30 Oct 2024 14:48:46 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated testing doc per PR comments

Marked as reviewed by rhalade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21551#pullrequestreview-2405597496

From mullan at openjdk.org  Wed Oct 30 16:48:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 16:48:15 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v6]
In-Reply-To: <TutLxRXjnc6TcdvvFuMXSgtR_YkWv57F5goFgDf0Ims=.d7e2ada9-fcc1-4bc7-be47-176c023d06e9@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <TutLxRXjnc6TcdvvFuMXSgtR_YkWv57F5goFgDf0Ims=.d7e2ada9-fcc1-4bc7-be47-176c023d06e9@github.com>
Message-ID: <MSpkk_SFFGWRdMkbaD2_Kb5ITm4yHEaxYTHpeRkTM5c=.f26f9e7c-f2e2-4f0a-8020-601202328a0e@github.com>

On Wed, 30 Oct 2024 14:48:46 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated testing doc per PR comments

doc/testing.html line 597:

> 595: <code>KeyFactory</code>, <code>Cipher</code>,
> 596: <code>KeyPairGenerator</code>, <code>KeyGenerator</code>, or
> 597: <code>SecretKeyFactory</code> objects. Specify the

I see some tests use a hard-coded provider for `Signature` too. Can you double-check all the changes and add any that you missed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21551#discussion_r1823022778

From duke at openjdk.org  Wed Oct 30 17:20:49 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 30 Oct 2024 17:20:49 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v3]
In-Reply-To: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
Message-ID: <V78g6WyyzPCDZyljQruRTCErpgGUY33N-fiGs4sc0g0=.0b663206-a5cd-4753-8de4-989e1935f51f@github.com>

> the implementation I originally provided does not in fact solve the issue!
> 
> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
> 
> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
> 
> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
> 
> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
> 
> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
> 
> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
> 
> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
> 
> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
> 
> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
> 
> therefore an "attacher" has two choices when attempting to attach:
> 
> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>   - this works with both peers and descendants
> 
> - use /tmp
>   - this only works if the "attacher" and "attachee" share a /tmp in common
> 
> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
> 
> In these circumstances, the "attacher" can only resort to /tmp wh...

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8342449: fixed missing param in throws msg and renamed local var

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21688/files
  - new: https://git.openjdk.org/jdk/pull/21688/files/4bee5d1e..2e89bd53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21688/head:pull/21688

PR: https://git.openjdk.org/jdk/pull/21688

From coleenp at openjdk.org  Wed Oct 30 17:26:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 17:26:28 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <48pRdCvEIvlz_mE1k0RcbMe5g41IwSakYibr8zzc13E=.ccfb704e-f5de-4cfa-b6c2-6fc4e76d58b6@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

src/hotspot/share/oops/stackChunkOop.inline.hpp line 189:

> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const {
> 188:   ObjectWaiter* waiter = object_waiter();
> 189:   if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) {

Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; }

Not sure what this is excluding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425

From kevinw at openjdk.org  Wed Oct 30 17:48:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 30 Oct 2024 17:48:09 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v3]
In-Reply-To: <V78g6WyyzPCDZyljQruRTCErpgGUY33N-fiGs4sc0g0=.0b663206-a5cd-4753-8de4-989e1935f51f@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
 <V78g6WyyzPCDZyljQruRTCErpgGUY33N-fiGs4sc0g0=.0b663206-a5cd-4753-8de4-989e1935f51f@github.com>
Message-ID: <4SMbf5RzhHhF8Ycgdc1XDDIK5c113qFGSVp8_NYN3Zo=.118d462f-455f-47e0-9e4d-8873ce1ae571@github.com>

On Wed, 30 Oct 2024 17:20:49 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the implementation I originally provided does not in fact solve the issue!
>> 
>> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
>> 
>> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
>> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
>> 
>> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
>> 
>> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
>> 
>> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
>> 
>> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
>> 
>> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
>> 
>> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
>> 
>> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
>> 
>> therefore an "attacher" has two choices when attempting to attach:
>> 
>> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>>   - this works with both peers and descendants
>> 
>> - use /tmp
>>   - this only works if the "attacher" and "attachee" share a /tmp in common
>> 
>> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
>> 
>> I...
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8342449: fixed missing param in throws msg and renamed local var

Looks good.  
So on the changed throw when not responding to sigquit, a locked up JVM will get the same message as always, as long as sigquit is caught and not blocked.
The new message will apply to e.g. non-JVM processes.

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21688#pullrequestreview-2405787887

From amenkov at openjdk.org  Wed Oct 30 18:06:10 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 30 Oct 2024 18:06:10 GMT
Subject: Integrated: 8343103: Enable debug logging for
 vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java
In-Reply-To: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
References: <OIvvhX0wJGbS7cr-TXmt2o1o5tNsxaqOLMg1COrdVzU=.57a83424-4646-4069-8711-41e3c935e1f2@github.com>
Message-ID: <ZDOPSj-vLcwzOh8SpHhqUY8Z9_aQrzfvuqvycGpRaic=.2cdbeb18-099d-4afd-bacd-3e076700e76b@github.com>

On Fri, 25 Oct 2024 22:44:49 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix enables logging in the test agent to get more details about intermittent failures.

This pull request has now been integrated.

Changeset: 1b177ce5
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b177ce5b7e25b3a563066ba92dbf8cacfd29126
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8343103: Enable debug logging for vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/TestDescription.java

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/21725

From mdonovan at openjdk.org  Wed Oct 30 18:12:30 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 30 Oct 2024 18:12:30 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v7]
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <ZnVJBXyRRwONxvPT8HLn7A_zslKZeN_W-5x59kFQ4iQ=.f53af548-3ab0-452f-b81b-69018fc2938a@github.com>

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  included additional services in testing.md

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21551/files
  - new: https://git.openjdk.org/jdk/pull/21551/files/3889e339..1436113e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21551&range=05-06

  Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21551.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21551/head:pull/21551

PR: https://git.openjdk.org/jdk/pull/21551

From mullan at openjdk.org  Wed Oct 30 18:50:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 18:50:05 GMT
Subject: RFR: 8341927: Replace hardcoded security providers with new
 test.provider.name system property [v7]
In-Reply-To: <ZnVJBXyRRwONxvPT8HLn7A_zslKZeN_W-5x59kFQ4iQ=.f53af548-3ab0-452f-b81b-69018fc2938a@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
 <ZnVJBXyRRwONxvPT8HLn7A_zslKZeN_W-5x59kFQ4iQ=.f53af548-3ab0-452f-b81b-69018fc2938a@github.com>
Message-ID: <NlPykFqTqYUlJDhfJFpSHpx5WCWtuQXc64EKCIeO7Zk=.d3467545-bfb1-42a3-bcaa-2bd9727bd930@github.com>

On Wed, 30 Oct 2024 18:12:30 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
>> 
>> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   included additional services in testing.md

Approving but I recommend a follow-on task be filed to check if some of these hard-coded providers are really necessary.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21551#pullrequestreview-2405973613

From mdonovan at openjdk.org  Wed Oct 30 18:54:25 2024
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 30 Oct 2024 18:54:25 GMT
Subject: Integrated: 8341927: Replace hardcoded security providers with new
 test.provider.name system property
In-Reply-To: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com>
Message-ID: <9sXgUcpENxfNt2A_oTMnAAZXCLxdi_orD_tuZ0asC2M=.b3293f5f-a8d2-4fa0-8c5f-343d6aaad661@github.com>

On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used:
> 
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE"));

This pull request has now been integrated.

Changeset: 9a9ac1d0
Author:    Matthew Donovan <mdonovan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a9ac1d0059438d33fe69ef51265dc7cff6ad2bd
Stats:     1007 lines in 230 files changed: 307 ins; 0 del; 700 mod

8341927: Replace hardcoded security providers with new test.provider.name system property

Reviewed-by: mullan, ascarpino, rhalade

-------------

PR: https://git.openjdk.org/jdk/pull/21551

From szaldana at openjdk.org  Wed Oct 30 19:04:11 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 30 Oct 2024 19:04:11 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v3]
In-Reply-To: <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
 <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
Message-ID: <2-p5KAclYCJNrpLkTqUq1J1J5o_KnO6PMUMA8mVv_ZM=.5b318397-7471-492f-bd89-230dfc1cb0ea@github.com>

On Thu, 17 Oct 2024 16:12:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Man page update for jcmd.
>> 
>> Add updates for the filename options/arguments affected by:
>> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
>> 
>> Also:
>> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
>> 
>> In Description:
>> Each diagnostic command has its own set of options and arguments .
>>  
>> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
>> 
>> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VM.cds remove unnecessary text

I'm not a Reviewer, but it looks good :)

-------------

Marked as reviewed by szaldana (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20401#pullrequestreview-2406007043

From iklam at openjdk.org  Wed Oct 30 19:14:12 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Oct 2024 19:14:12 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <ZlzUKcGyjkJXpZ6IbaVy90ZnxVjFkEi0a-Uf0fLVov4=.c06e3163-4cdb-46f1-9499-a28a9fcef54c@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
 <ZlzUKcGyjkJXpZ6IbaVy90ZnxVjFkEi0a-Uf0fLVov4=.c06e3163-4cdb-46f1-9499-a28a9fcef54c@github.com>
Message-ID: <X5-Fo66-BF7LwRP-fpauPms6FS4SSinGE5LwA5XoIWs=.176886bb-5cf6-428c-8130-9f0e02f21bfc@github.com>

On Thu, 24 Oct 2024 06:14:18 GMT, John R Rose <jrose at openjdk.org> wrote:

> A thought for a possible cleanup, after this PR is done?
> 
> The scratch mirror logic had me? scratching my head. It seems to me that a more descriptive name would make the code explain itself better. I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset"). This is in distinction to the current "live" mirror, which is also the AOT phase mirror. In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term. But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase). In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure.
> 
> (When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else? Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.)

The cached heap objects are mostly copied as-is, with a recursive walk from a set of roots. However, in some cases, we need to perform transformation in some of the objects. The transformation is implemented by substituting some of the discovered objects with a "scratch" (or "future") version.

For example, for java mirrors:

- If a class K1 *is not* aot-initialized, we need to zero out most of the fields inside `K1->java_mirror()`, but keep the injected `klass` and `array_klass` native pointers.
- If a class K2 *is* aot-initialized, we need to also keep the static fields declared in Java code in `K2->java_mirror()`

For example, here are the contents of the aot-cached mirror for the java/lang/String class:


 - ---- fields (total size 17 words):
 - private volatile transient 'classRedefinedCount' 'I' @12  0 (0x00000000)
 - injected 'klass' 'J' @16  2684621920 (0x00000000a0041460)
 - injected 'array_klass' 'J' @24  2684707368 (0x00000000a0056228)
 - injected 'oop_size' 'I' @32  17 (0x00000011)
 - injected 'static_oop_field_count' 'I' @36  2 (0x00000002)
 - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40  null (0x00000000)
 - private transient 'name' 'Ljava/lang/String;' @44  null (0x00000000)
 - private transient 'module' 'Ljava/lang/Module;' @48  null (0x00000000)
 - private final 'classLoader' 'Ljava/lang/ClassLoader;' @52  null (0x00000000)
 - private transient 'classData' 'Ljava/lang/Object;' @56  null (0x00000000)
 - private transient 'signers' '[Ljava/lang/Object;' @60  null (0x00000000)
 - private transient 'packageName' 'Ljava/lang/String;' @64  null (0x00000000)
 - private final 'componentType' 'Ljava/lang/Class;' @68  null (0x00000000)
 - private volatile transient 'reflectionData' 'Ljava/lang/ref/SoftReference;' @72  null (0x00000000)
 - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @76  null (0x00000000)
 - private volatile transient 'enumConstants' '[Ljava/lang/Object;' @80  null (0x00000000)
 - private volatile transient 'enumConstantDirectory' 'Ljava/util/Map;' @84  null (0x00000000)
 - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @88  null (0x00000000)
 - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @92  null (0x00000000)
 - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @96  null (0x00000000)
 - injected 'protection_domain' 'Ljava/lang/Object;' @100  null (0x00000000)
 - injected 'source_file' 'Ljava/lang/Object;' @104  null (0x00000000)
 - injected '<init_lock>' 'Ljava/lang/Object;' @108  [I{0x000000060ec016b0} (0xc1d802d6)
 - signature: Ljava/lang/String;
 - ---- static fields (2):
 - private static final 'serialVersionUID' 'J' @120  -6849794470754667710 (0xa0f0a4387a3bb342)
 - static final 'COMPACT_STRINGS' 'Z' @130  true (0x01)
 - private static final 'serialPersistentFields' '[Ljava/io/ObjectStreamField;' @112  a 'java/io/ObjectStreamField'[0] {0x000000060ec0e468} (0xc1d81c8d)
 - private static final 'REPL' 'C' @128    65533 (0xfffd)
 - public static final 'CASE_INSENSITIVE_ORDER' 'Ljava/util/Comparator;' @116  a 'java/lang/String$CaseInsensitiveComparator'{0x000000060ec0e7a8} (0xc1d81cf5)
 - static final 'LATIN1' 'B' @131  0 (0x00)
 - static final 'UTF16' 'B' @132  1 (0x01)


Here's a matrix for deciding when a field is kept or zeroed out:


Field              Type                     Not-AOT-inited   AOT-inited
-------------------------------------------------------------------------                               
"klass"            injected by HotSpot      keep             keep
"COMPACT_STRINGS"  declared in String.java  zero             keep
"module"           field of j.l.Class       zero             zero


After JEP 483 is integrated, I will investigate if the transformation can be done inside the recursive copying code without the substitution of scratch (future) objects.

An alternative to substitution would be to modify the original Java mirrors (to zero out fields that we don't want to cache), but that will damage the state of the VM. That's something CDS has been avoiding doing -- we want the VM to be useable after the AOT cache is written.

Of course, the holy grail is to avoid any transformation and simply cache everything as-is, in a snapshot style. We can't do that yet as the AOT cache still requires some "loading" operations in the production run. Some of the loading code, for example, might be confused if it sees `module` to be non-null when an aot-inited class is loaded into the JVM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2448132377

From kvn at openjdk.org  Wed Oct 30 19:28:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:28:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <X7DL3g4Y1-HUMBoX2v0xWzSe_ydqOJHAboDro1I0alA=.b3502a5a-224e-4aae-a955-a6f1f62805f2@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

There is useless code in `src/hotspot/cpu//x86/interpreterRT_x86_32.cpp` which is guarded by `#ifdef AMD64` which is false for 32-bit.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2406069434

From mullan at openjdk.org  Wed Oct 30 19:28:32 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:28:32 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Modify three RMI tests to work without the security manager:
    - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
    - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
    - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
   Also remove them from the problem list.
 - Remove two obsolete RMI tests:
    - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
    - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
   Adjust two tests to run without the Security Manager:
    - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
    - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
   Remove all of these tests from the problem list.
 - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
 - Added API Notes to ProtectionDomain clarifying that the current policy always
   grants no permissions. A few other small changes to Policy and PD.
 - Merge branch 'master' into jep486
 - JAXP tests: organize imports of a few tests
 - Improve description of Executors.privilegedThreadFactory
 - rename TestAppletLoggerContext.java as suggested in util test review
 - clientlibs: Javadoc cleanup
 - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=05
  Stats: 68829 lines in 1886 files changed: 2485 ins; 62501 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From kvn at openjdk.org  Wed Oct 30 19:36:33 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:36:33 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <M7euyT-eOyKa6wBKIdzfewGt_uT99-HGPeOSHXtcHPE=.f16fb74e-57ae-4c99-a147-0b90b25ede6e@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

There are several combinations of `#ifdef _WINDOWS / #ifdef _LP64` in `src/hotspot//cpu/x86/vm_version_x86.cpp` and may be other places: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L515

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448187637

From coleenp at openjdk.org  Wed Oct 30 19:38:33 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 19:38:33 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

I've traced through the runtime code (minus calculations for continuations) and found some typos on the way.  Excellent piece of work.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:

> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
> 2234:       if (!mon_acquired) {
> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.

typo: acquire

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:

> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.

typo: can be walked

src/hotspot/share/runtime/javaThread.hpp line 334:

> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback

typo: Monitor **for** pending_contended_entered callback

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823233359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373

From coleenp at openjdk.org  Wed Oct 30 19:38:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 30 Oct 2024 19:38:36 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
Message-ID: <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>

On Tue, 29 Oct 2024 23:16:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
> 
>> 1409:     // zero out fields (but not the stack)
>> 1410:     const size_t hs = oopDesc::header_size();
>> 1411:     oopDesc::set_klass_gap(mem, 0);
> 
> Why, bug fix or cleanup?

This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312

From kvn at openjdk.org  Wed Oct 30 19:40:19 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:40:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

Bug in `macroAssembler_x86.cpp` - should be `_WINDOWS`

src/hotspot//cpu/x86/macroAssembler_x86.cpp:#ifndef WINDOWS
src/hotspot//cpu/x86/macroAssembler_x86.cpp:#if defined(WINDOWS) && defined(_LP64)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448195812

From kvn at openjdk.org  Wed Oct 30 19:44:34 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:44:34 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <KSWNrkuRf4_G_XIRkBtf4TxRj73DMQxNGdsQLzNIA58=.5bda552c-c29d-4d35-9e1c-961f14e28f33@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

We may remove next code too: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/compilerDefinitions.cpp#L563

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448203927

From mullan at openjdk.org  Wed Oct 30 19:46:51 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:46:51 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <lZcOTgw-GDnWydfumYS8_S_FKYztRvpJUdExxx0_pu4=.ef9178a6-ae67-40df-875d-d69968e75324@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Main changes in latest update include:

- Resolution of 6 remaining RMI related tests on the ProblemList by removing or replacing SM dependencies
- Added several API Notes to the `ProtectionDomain` to note that the "current policy" always grants no permissions.
- Updated definition of `networkaddress.cache.ttl` security property and removed specified behavior when Security Manager is enabled.
- Adjusted wording of `Executors.privilegedThreadFactory` and `privilegedCallable` to clarify use of current classloader
- A few miscellaneous fixes to tests, see other comments for pointer to fixes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448208886

From mullan at openjdk.org  Wed Oct 30 19:52:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 19:52:47 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <1CWe1-L-oMdW3tMpGULQmZNZS_1wUHhgkzh9j9i5jHY=.7f6f47ce-f07e-4c23-a445-14b0beea70b8@github.com>
Message-ID: <WxVLgqtMTy2s4lu6__o0VRy59hAVkG7THNCACepN8Lk=.93d6e4e8-ad7a-451c-ac19-7593a3a95ec2@github.com>

On Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>> 
>>> 1611:      * interpreted as a {@code Font} object according to the
>>> 1612:      * specification of {@code Font.decode(String)}
>>> 1613:      * If the specified property is not found then null is returned instead.
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, null is returned instead.
>> 
>> The old description didn't have ?then?, it can be dropped. A comma to separate the conditional clause from the main one makes the sentence easier to read.
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

>> src/java.desktop/share/classes/java/awt/Font.java line 1781:
>> 
>>> 1779:      * The property value should be one of the forms accepted by
>>> 1780:      * {@code Font.decode(String)}
>>> 1781:      * If the specified property is not found then the {@code font}
>> 
>> Suggestion:
>> 
>>      * If the specified property is not found, the {@code font}
>
> Updated on jep486 branch

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/90469c2e42d0259d032a7bdf3be20d81e9fb8fac

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297079
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823297577

From kvn at openjdk.org  Wed Oct 30 19:56:35 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 30 Oct 2024 19:56:35 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
Message-ID: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>

On Wed, 30 Oct 2024 11:18:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Error in os_windows.cpp for unknown cpu

`grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2448239347

From wkemper at openjdk.org  Wed Oct 30 20:15:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Oct 2024 20:15:52 GMT
Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah
 (Experimental) [v5]
In-Reply-To: <L8N4NbS_URQkt0cLY8s3UajQEFoL1L_fg25K4pntzS0=.fa6cbb88-e95d-4f81-ac04-2a9b1174a5ac@github.com>
References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com>
 <FMQHoGfcWxoMldgl3JRvFvUKqOuu1N-YSv6qSkRmBjA=.9bea9619-d7f3-4834-bbf3-5a05e73c17a3@github.com>
 <ABXS9VGZgO5rYX2O_cjToFf5Mv1kDSia2hMvA95BbGM=.01ddfdca-38e4-4440-b677-811a2f9c6805@github.com>
 <L8N4NbS_URQkt0cLY8s3UajQEFoL1L_fg25K4pntzS0=.fa6cbb88-e95d-4f81-ac04-2a9b1174a5ac@github.com>
Message-ID: <0ymPZeZsrtfMJd1-5w_4Ciw0tAxMtSoaS8mGoOO9Kr8=.f4b59791-21bd-4e51-aefb-ffaeccddeec6@github.com>

On Wed, 30 Oct 2024 02:09:46 GMT, Liang Mao <lmao at openjdk.org> wrote:

>> We disabled tiered compilation to force everything to compile through C2 to get more consistent results.
>
> @earthling-amzn ?thanks for providing your options. Looks like disabling pacing would help the score. 
> 
> -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC
> 
> I guess 4 cores may not be a target configuration for pauseless GC since generational pauseless GC requires at least 2 concurrent GC threads that already occupy half of CPU resource. I did a rough test on 8 cores and 16 cores according to your options. GenShen doesn't have obvious advantages with 8 cores and Shenandoah seems to outperform genshen significantly with 16 cores. Would you please help verify the result in your environment?
> 
> 8 cores -Xmx8g -Xms8g:
> 
> GenShen:
> RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 8098, critical-jOPS = 6132
> RUN RESULT: hbIR (max attempted) = 8944, hbIR (settled) = 8574, max-jOPS = 7781, critical-jOPS = 6130
> 
> Shenandoah:
> RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 7616, critical-jOPS = 6194
> RUN RESULT: hbIR (max attempted) = 9640, hbIR (settled) = 8050, max-jOPS = 7712, critical-jOPS = 6262
> 
> 16 cores -Xmx20g -Xms20g:
> 
> GenShen:
> RUN RESULT: hbIR (max attempted) = 19881, hbIR (settled) = 16584, max-jOPS = 17694, critical-jOPS = 13274
> RUN RESULT: hbIR (max attempted) = 19881, hbIR (settled) = 18724, max-jOPS = 17694, critical-jOPS = 13445
> Shenandoah:
> RUN RESULT: hbIR (max attempted) = 23838, hbIR (settled) = 20446, max-jOPS = 18594, critical-jOPS = 15441
> RUN RESULT: hbIR (max attempted) = 20138, hbIR (settled) = 19989, max-jOPS = 18728, critical-jOPS = 14967

@mmyxym - I disabled Shenandoah's pacer, and find that the generational mode out performs the non-generational mode:

Shen: RUN RESULT: hbIR (max attempted) = 16584, hbIR (settled) = 13837, max-jOPS = 11609, critical-jOPS = 11062
Shen: RUN RESULT: hbIR (max attempted) = 16584, hbIR (settled) = 13837, max-jOPS = 11609, critical-jOPS = 10425

Gen:  RUN RESULT: hbIR (max attempted) = 16584, hbIR (settled) = 14144, max-jOPS = 13267, critical-jOPS = 12087
Gen:  RUN RESULT: hbIR (max attempted) = 16584, hbIR (settled) = 13837, max-jOPS = 13267, critical-jOPS = 12151

The shared options for these runs were:

"-Xmx8g -Xms8g -XX:ActiveProcessorCount=8 -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:MetaspaceSize=1g -XX:-ShenandoahPacing

This is an aarch64 host with 16 cores and 64G of memory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2448245419

From mullan at openjdk.org  Wed Oct 30 20:16:42 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6l6E8GJkCbLzSHBVRKh4wfOKXZ2wVDnj1c1yivmx_60=.3e38ebec-9bdc-497b-89ab-d9beda86fb9b@github.com>
 <swhgv7tTLxYzI03ZtCsWD2HcC1gRJ9RuyqWNja9wnWc=.9f092c2f-f706-4587-a695-1636e583cfb2@github.com>
Message-ID: <24vtAM0Ez1gNMgD69tDo3tvSJttBAB27n6S3du1YCI0=.3f968953-0bd9-4e8c-b77d-ef351f232116@github.com>

On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Comments on `java.security` classes.
> 
> Also, I'd like to see some clarifications on what "the installed policy" or "the current policy" is. The `ProtectionDomain` mentions this when talking about dynamic permissions. On the other hand, the `Policy` class suggests there is no such a thing. If we do not have this concept no more, some modifications might be needed in `ProtectionDomain`.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/376d1b58bd442143ed9dc48c7d38cb5535af1569

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448236942

From mullan at openjdk.org  Wed Oct 30 20:16:43 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:43 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <EXxtSzzTbD8mYSJQiQRkLBr05_1ulVw29FBt3ovucqY=.e5b1c6d3-18f1-4b0a-abd7-88eca4b5f07d@github.com>
Message-ID: <GPn_TYX-s1iHAu2QRhyA6fZq0IY8QEj3151WQP3O44c=.5224e14c-d59c-4c01-a3cf-cf0a64bc998a@github.com>

On Mon, 28 Oct 2024 20:12:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around unnecessarily but otherwise looks fine.

JAXP test comments fixed in https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2448243564

From mullan at openjdk.org  Wed Oct 30 20:16:46 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:46 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v5]
In-Reply-To: <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <kfjTzVSV81j-pVHjP0hNXtjm0V-5PZKuxicAM3bqgiM=.fd14cf39-b7e2-4501-8c5b-866d03846710@github.com>
 <9p1PtYvPS5k2epjlmaLczSwHuolgh_7V6Bzjf9y5ywU=.5839586d-3942-4093-9c1b-b87f38980017@github.com>
Message-ID: <eWQL7DYj1uuJ1CPxnHlGcggMuMiMzOOXFPDGrAbLQKM=.eb6e1333-eb8c-4d23-bca8-200a22e34ccd@github.com>

On Tue, 29 Oct 2024 18:35:05 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 186 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Update copyrights. Remove @compile line form Marshal.java test.
>>  - Update copyright headers
>>  - Adjust Executors.privilegedThreadFactory to make clear that thread uses current CCL
>>  - Merge branch 'master' into jep486
>>  - ResourceBundle/modules/security/* no longer needed. TestPermission tested against getModule(String, Module) w/ SM.
>>  - remove privileged calls in logging/File* tests
>>  - delete PermissionTest.java as it simply constructs provider impls
>>  - remove non enforced/redundant comment in TestLogConfigurationDeadLockWithConf.java
>>  - clientlibs: Updated javax/swing/UIDefaults/6622002/bug6622002.java
>>    Removed createPrivateValue(), no longer used.
>>  - ... and 176 more: https://git.openjdk.org/jdk/compare/df3473e2...2f90c839
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 392:
> 
>> 390:     /**
>> 391:      * Returns a thread factory used to create new threads that
>> 392:      * have current context class loader as the context class loader.
> 
> One nit for your consideration: "...to create new threads that have **_the_** current context class loader..."

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/06c4c3c1ab1fe121b625bd30a0c424be06d5022a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823307856

From pchilanomate at openjdk.org  Wed Oct 30 20:16:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.79dd72d1-947c-4794-b450-0dd273661136@github.com>
Message-ID: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.1dc24cd9-9de2-4fd3-8a38-def6dfe2dbda@github.com>

On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:
> 
>> 1080:     } else {
>> 1081:       assert(vthread != nullptr, "no vthread oop");
>> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);
> 
> Nit: The name `oopCont` does not match the HotSpot naming convention.
>        What about `cont_oop` or even better just `cont` as at the line 2550?

Renamed to cont.

> src/hotspot/share/prims/jvmtiExport.cpp line 1682:
> 
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
>> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));
> 
> I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

Right, good find. I missed `get_jvmti_thread_state ` will also create the state if null. How about this fix: https://github.com/pchilano/jdk/commit/baf30d92f79cc084824b207a199672f5b7f9be88
I now also see that JvmtiVirtualThreadEventMark tries to save some state of the JvmtiThreadState for the current thread before the callback, which is not the JvmtiThreadState of the vthread for this case. Don't know if something needs to change there too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449

From mullan at openjdk.org  Wed Oct 30 20:16:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:48 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <6NbM9niKSF1sBdrZ24XUgQ3fhuwI6XNZ1UFSzYDDNUY=.a7728a42-387d-4541-87dc-64654d4a8dc7@github.com>
Message-ID: <QDRmqh8JFZp8wqckrMDjRg-xZqTsqh2gMS35zax4RF4=.6f15599e-85ff-40aa-b736-b8f64074faa1@github.com>

On Fri, 25 Oct 2024 20:44:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/util/logging/TestAppletLoggerContext.java line 40:
> 
>> 38:  * @modules java.base/jdk.internal.access
>> 39:  *          java.logging
>> 40:  * @run main/othervm TestAppletLoggerContext LoadingApplet
> 
> Rename these?  What's really being tested, there are no more Applets.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/444fabe80a7b53ba208db99d69b9778a6113454d

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823302577

From pchilanomate at openjdk.org  Wed Oct 30 20:16:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Rename oopCont + fix in JvmtiUnmountBeginMark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/9fd4c036..63003d37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=18-19

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 20:16:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
Message-ID: <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>

On Wed, 30 Oct 2024 09:44:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/share/runtime/continuation.cpp line 88:
> 
>> 86:       if (_target->has_async_exception_condition()) {
>> 87:         _failed = true;
>> 88:       }
> 
> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

> src/hotspot/share/runtime/continuation.cpp line 115:
> 
>> 113:       if (jvmti_present) {
>> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
>> 115:         if (JvmtiExport::should_post_vthread_mount()) {
> 
> This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
> Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

Fixed and added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891

From mullan at openjdk.org  Wed Oct 30 20:16:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 30 Oct 2024 20:16:49 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v4]
In-Reply-To: <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
 <CRG5eEdT4KNf-oYo6V0_flBE0A34uG4Pae3FsO1KWB4=.adfef5e4-303d-49b8-bb61-1cea38f71770@github.com>
Message-ID: <GJqcqELAGDX0uDd55OOoblexMod-v5ByE02XvOpUx6M=.fb5f6f0b-66e8-4c47-b045-c99b5989df3e@github.com>

On Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>> 
>>> 1: /*
>> 
>> @wangweij It looks like this test can be deleted as it was specifically trying to check that a `SecurityException` wasn't thrown, or did you think it was still testing something useful?
>
> It can be removed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/b2d59a432d6472263c1706d9dbb83c99cbf79793

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1823306809

From pchilanomate at openjdk.org  Wed Oct 30 20:16:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 20:16:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <LZimLKg9C6gbUxhpq7cLieIlQo1EuwC-4hlWxU7I-nY=.82664197-146a-4f18-b2b2-917af157db75@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.af2172e4-be1a-4f43-9c48-7e3b65308a61@github.com>
Message-ID: <ZELBjBKJitCg3vuMgSg_zsAmoOd6w3yxzlrWsHs8icg=.bd59eae1-ce5f-465a-b059-4ee8ca7a6f24@github.com>

On Mon, 21 Oct 2024 09:55:53 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename oopCont + fix in JvmtiUnmountBeginMark
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:
> 
>> 2536:   Method* m = hf.interpreter_frame_method();
>> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
>> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;
> 
> Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

I reverted this change and added an assert instead, since for native methods we always thaw the caller too, i.e. it will not be the bottom frame. I added a comment in the other two references for the extra native slots in continuationFreezeThaw_x86.inline.hpp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839

From kevinw at openjdk.org  Wed Oct 30 20:22:03 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 30 Oct 2024 20:22:03 GMT
Subject: RFR: 8337276: jcmd man page update for PID in output filenames
 [v3]
In-Reply-To: <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
 <-QbZdgT3weWFl9ZbNsf_CTxTcTf1c6A9OK1_F0uSFEk=.7bbad5c6-c546-4c7e-a578-3b804bc96ca8@github.com>
Message-ID: <mYsFwDNGNOyMo5AGPRDGBanW5_AjFwjnwaLUJulxP5c=.4f6af763-2c64-42cc-b831-43facca996e8@github.com>

On Thu, 17 Oct 2024 16:12:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Man page update for jcmd.
>> 
>> Add updates for the filename options/arguments affected by:
>> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
>> 
>> Also:
>> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
>> 
>> In Description:
>> Each diagnostic command has its own set of options and arguments .
>>  
>> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
>> 
>> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   VM.cds remove unnecessary text

Thanks Chris and Sonia!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20401#issuecomment-2448287143

From jlu at openjdk.org  Wed Oct 30 20:43:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Oct 2024 20:43:02 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
 <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
Message-ID: <aynKsg_d9tERx3eWbwx9Pai29bRfYDjhTZJJ4ZzD5E8=.2bf3bb18-b265-49b6-ab51-42ac884f6e71@github.com>

On Tue, 29 Oct 2024 00:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 
>> 
>> 
>> 
>>>     ExceptionCheck
>>>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
>>> 
>>>     jboolean ExceptionCheck(JNIEnv *env);
>>> 
>>>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address other cases in Hotspot

Thank you for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21724#issuecomment-2448314389

From iklam at openjdk.org  Wed Oct 30 20:43:09 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 30 Oct 2024 20:43:09 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <X5-Fo66-BF7LwRP-fpauPms6FS4SSinGE5LwA5XoIWs=.176886bb-5cf6-428c-8130-9f0e02f21bfc@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
 <ZlzUKcGyjkJXpZ6IbaVy90ZnxVjFkEi0a-Uf0fLVov4=.c06e3163-4cdb-46f1-9499-a28a9fcef54c@github.com>
 <X5-Fo66-BF7LwRP-fpauPms6FS4SSinGE5LwA5XoIWs=.176886bb-5cf6-428c-8130-9f0e02f21bfc@github.com>
Message-ID: <XcfbIpRepetTWJArY4r5qlPqDxWYDi18lFgmtjaESa0=.e7daceae-815f-453d-81d9-32eda0d7dd92@github.com>

On Wed, 30 Oct 2024 19:11:46 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> A thought for a possible cleanup, after this PR is done?
>> 
>> The scratch mirror logic had me? scratching my head.  It seems to me that a more descriptive name would make the code explain itself better.  I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset").  This is in distinction to the current "live" mirror, which is also the AOT phase mirror.  In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term.  But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase).  In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure.
>> 
>> (When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else?  Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.)
>
>> A thought for a possible cleanup, after this PR is done?
>> 
>> The scratch mirror logic had me? scratching my head. It seems to me that a more descriptive name would make the code explain itself better. I suggest (for a future cleanup) calling a mirror structure which is being aot-assembled (just for the archive) a "future mirror" (or maybe "production mirror" or "mirror asset"). This is in distinction to the current "live" mirror, which is also the AOT phase mirror. In general, from the point of view of the assembly phase, when we build new structures not created by the JVM as a result of post-training Java execution, we might want to give them a common descriptive term. But I suppose most items that make it into the AOT cache are faithful copies of live data, present in the VM at dump time (end of assembly phase). In that case, it's more like "the same structure" in all cases, and there's no need to simultaneously work on both present and future versions of the same structure.
>> 
>> (When I say "structure" I mean mirror object for now, but perhaps the pattern might expand to something else? Or, maybe we will get rid of the two-mirror solution, in which case every future structure is also completely present and live in the assembly-phase VM.)
> 
> The cached heap objects are mostly copied as-is, with a recursive walk from a set of roots. However, in some cases, we need to perform transformation in some of the objects. The transformation is implemented by substituting some of the discovered objects with a "scratch" (or "future") version.
> 
> For example, for java mirrors:
> 
> - If a class K1 *is not* aot-initialized, we need to zero out most of the fields inside `K1->java_mirror()`, but keep the injected `klass` and `array_klass` native pointers.
> - If a class K2 *is* aot-initialized, we need to also keep the static fields declared in Java code in `K2->java_mirror()`
> 
> For example, here are the contents of the aot-cached mirror for the java/lang/String class:
> 
> 
>  - ---- fields (total size 17 words):
>  - private volatile transient 'classRedefinedCount' 'I' @12  0 (0x00000000)
>  - injected 'klass' 'J' @16  2684621920 (0x00000000a0041460)
>  - injected 'array_klass' 'J' @24  2684707368 (0x00000000a0056228)
>  - injected 'oop_size' 'I' @32  17 (0x00000011)
>  - injected 'static_oop_field_count' 'I' @36  2 (0x00000002)
>  - private volatile transient 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @40  null (0x00000000)
>  - private transient 'name' 'Ljava/lang/String;' @44  null...

> @iklam I remember there was [ConstantPool::iterate_archivable_resolved_references](https://github.com/iklam/jdk/blob/f0bc1ae60fea80d5914d520457986a753e75fae4/src/hotspot/share/oops/constantPool.cpp#L288) in #21143 but I don't see it any more in this PR. Can you please comment on why was that removed?

An indy call site has two entries in the resolved_references array:
- (a) The resolved call site
- (b) The MethodHandle of the boot strap method

We weren't archiving (b), which caused some JIT replay code to fail (the JIT assumes that both (a) and (b) must be resolved together). To fix this problem, I added the archiving of (b) in https://github.com/openjdk/jdk/pull/21642/commits/1d3daa4299691e75450d56ed1608b77e75cfd00a

Afterwards, I realized that we can simply archive everything in the resolved_reference array, because AOTConstantPoolResolver::is_indy_resolution_deterministic() already ensures that we only resolve indys that we can support. `ConstantPool::iterate_archivable_resolved_references()` is no longer necessary as it simply repeats the checks in `is_indy_resolution_deterministic()`. That's why I removed it in 
https://github.com/openjdk/jdk/pull/21642/commits/1d3daa4299691e75450d56ed1608b77e75cfd00a

But, now I realized that this part is also removed, which is probably not good.


    Array<ResolvedMethodEntry>* method_entries = cache()->resolved_method_entries();
    if (method_entries != nullptr) {
      for (int i = 0; i < method_entries->length(); i++) {
        ResolvedMethodEntry* rme = method_entries->adr_at(i);
        if (rme->is_resolved(Bytecodes::_invokehandle) && rme->has_appendix() &&
            cache()->can_archive_resolved_method(this, rme)) {
          int rr_index = rme->resolved_references_index();
          assert(resolved_reference_at(rr_index) != nullptr, "must exist");
          function(rr_index);
        }
      }
    }


For safety, I will revert the removal. We can consider refactoring the code after 483 is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2448302959

From dholmes at openjdk.org  Wed Oct 30 21:10:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 21:10:37 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
 <dD4eisKcehzlADXIFXCroCtk3-1YU2qAFKGv8wDHVnM=.a6fa25c8-51e5-4e9a-870b-1e2f84833b3f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.7e443b8b-093e-4ec5-a542-6b881563082b@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.d18fa391-6a71-469f-8150-3b10aa85b80f@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.d51939e5-6c96-471e-b64e-e26eb4fbb099@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.54a93a7a-8b43-4221-a565-d569ba98ab6e@github.com>
 <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.cf318be5-c4d2-428f-a1d4-f8616490e190@github.com>
Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.939669fc-f0bc-49fc-8b00-3abe4beb846b@github.com>

On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.
>
> Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:
> 
> |                ThreadA                |                   ThreadB             |           ThreadC             |
> | --------------------------------------| --------------------------------------| ---------------------------------------------|
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
> |                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
> |                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
> |                                       | ExitEpilog:releases monitorB          |                                              |
> |                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
> |                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
> |                                       |                                       |     continues execution in Java              |
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
> |                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
> |  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
> |  ExitEpilog:releases monitorA         |                                       |                                              |
> |  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886

From dholmes at openjdk.org  Wed Oct 30 21:20:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 30 Oct 2024 21:20:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v20]
In-Reply-To: <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <F_i9h7zhhSfGWbQAIkqt8VChnZ6B7rHLtKJJUkK7clY=.6d1d8125-afb2-4707-9250-b26f1a1ad702@github.com>
Message-ID: <_feLyxFARa2bfW3YLKwRvzGE9Cmp8d-nWVUOo0uGa8g=.2fbee6c3-6339-461d-bfbb-2ffcbb507c22@github.com>

On Wed, 30 Oct 2024 20:16:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename oopCont + fix in JvmtiUnmountBeginMark

Updates look good - thanks.

I think I have nothing further in terms of the review process. Great work!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095

From jlu at openjdk.org  Wed Oct 30 21:53:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 30 Oct 2024 21:53:11 GMT
Subject: Integrated: 8341788: Fix ExceptionOccurred in hotspot
In-Reply-To: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
Message-ID: <5weSq-fu92Wf9-C5llQX5THwb93iUQyOUjlLPYZCbmU=.1bada3ef-9fe2-43b0-a065-9e8e0611a1d0@github.com>

On Fri, 25 Oct 2024 21:51:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

> A trivial JNI refactoring in Hotspot to use `ExceptionCheck()` over `ExceptionOccurred()` when the usage is treating the return value as a boolean. This is part of the bigger umbrella issue: [JDK-8341542](https://bugs.openjdk.org/browse/JDK-8341542). 
> 
> 
> 
>>     ExceptionCheck
>>     We introduce a convenience function to check for pending exceptions without creating a local reference to the exception object.
>> 
>>     jboolean ExceptionCheck(JNIEnv *env);
>> 
>>     Returns JNI_TRUE when there is a pending exception; otherwise, returns JNI_FALSE.

This pull request has now been integrated.

Changeset: 7461dfe9
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7461dfe9c652542ef4e8f8fe36ac601ebd345492
Stats:     13 lines in 7 files changed: 0 ins; 0 del; 13 mod

8341788: Fix ExceptionOccurred in hotspot

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/21724

From kevinw at openjdk.org  Wed Oct 30 21:57:56 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 30 Oct 2024 21:57:56 GMT
Subject: Integrated: 8337276: jcmd man page update for PID in output filenames
In-Reply-To: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
References: <weio0ubnSznZBlADvd0KW0AkoFWMCeLRMf4sL7Kmo38=.1f8da8d3-b4f1-48d1-ad61-6ff3c64ce3e4@github.com>
Message-ID: <8UHg8ZjdDnq3uElvN9JobJpwmghO0P_Xhrr-1cn-FY4=.e13672ff-8878-4236-8dea-d19b7673bfda@github.com>

On Wed, 31 Jul 2024 08:30:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Man page update for jcmd.
> 
> Add updates for the filename options/arguments affected by:
> 8334492: DiagnosticCommands (jcmd) should accept %p in output filenames and substitute PID
> 
> Also:
> In the initial "command" summary, remove the text about "If the pid is 0.." as it is completely duplicated very shortly afterwards in the COMMANDS FOR JCMD section.
> 
> In Description:
> Each diagnostic command has its own set of options and arguments .
>  
> Added "options and" because arguments and options are different and this can still be confusing.  Mentioning them as being different may help.
> 
> Similarly, added a short section describing that jcmds "may take options and arguments" and further spelling out that options are name=value and arguments are not, as this can still be confusing.

This pull request has now been integrated.

Changeset: cc2fb4d3
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc2fb4d3bd52a0f0b2c92e0b5490e003f9ba55ee
Stats:     46 lines in 1 file changed: 10 ins; 18 del; 18 mod

8337276: jcmd man page update for PID in output filenames

Reviewed-by: cjplummer, szaldana

-------------

PR: https://git.openjdk.org/jdk/pull/20401

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v21]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <hM7vyfAwIsZhjjsv0s4k4gzTzQhJCXE6qVDUfs2QpZk=.b71426d3-908f-449f-96f7-b86ff51d0c2f@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - SmallRegisterMap::instance() fix + comment typo
 - Add comment in call_VM_preemptable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/63003d37..aa682de2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=19-20

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <xMbpro8ioob98t7Q0wPB9W_Rz-XXwWWp35Nq1-RWLMA=.28f048fa-8a61-4075-846d-8edfb3b553fd@github.com>
 <w3Wf-PGaVmIHDFRqD9D2hcgN_xQUbwPLADKUHEH95S4=.40aebb13-050b-411a-90e9-dabab4e16a26@github.com>
 <kOVKmJrHl_HJKOj5fH_SszYQX1yC3Nfe3IyZwm3BLjY=.fb02efdf-df19-4cf3-b5c7-bae736362da5@github.com>
Message-ID: <Go3eRJLPZ-G7dhFInCPSbRD-Zr7AtweuOE6jFZPX2Vw=.4ece3b76-0349-43fc-b79e-18c717d093bd@github.com>

On Tue, 29 Oct 2024 20:57:48 GMT, Dean Long <dlong at openjdk.org> wrote:

>> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.
>
> `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

I think aarch64 is the correct one. For interpreter frames we also have a sender_sp() that we get through that offset value: https://github.com/openjdk/jdk/blob/7404ddf24a162cff445cd0a26aec446461988bc8/src/hotspot/cpu/x86/frame_x86.cpp#L458
I think the confusion is because we also have interpreter_frame_sender_sp_offset where we store the unextended sp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787

From pchilanomate at openjdk.org  Wed Oct 30 22:18:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <vQyZh7evBajBq4YIZKhJXN5B9wgKSlAHplwqFHpXL8E=.5d9895c2-cfd7-41e6-aa7c-29d64e095c6b@github.com>
Message-ID: <XzzSB-Dc6W-U5Iv31bsokNTokJFKCc_KY_7ylmRpMcs=.a9acc6bc-3132-42b4-bf34-a2743be5adc8@github.com>

On Wed, 30 Oct 2024 00:52:32 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:
> 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 360:   lea(rscratch1, resume_pc);
>> 361:   push(rscratch1);
> 
> Suggestion:
> 
>   push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

Added it as a note with the comment above.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:
> 
>> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
>> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
>> 2045:     // frame effectively overwritting the restored registers during that call.
> 
> Suggestion:
> 
>     // frame effectively overwriting the restored registers during that call.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823511520

From pchilanomate at openjdk.org  Wed Oct 30 22:18:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v21]
In-Reply-To: <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
Message-ID: <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>

On Wed, 30 Oct 2024 01:52:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - SmallRegisterMap::instance() fix + comment typo
>>  - Add comment in call_VM_preemptable
>
> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.PreemptStatus() in Continuation.java
> 
> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

`PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823509538

From pchilanomate at openjdk.org  Wed Oct 30 22:18:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:18:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <M8wAmhYNAY7xruAAVdy2D90rvL94zbfRR1vkzjdWeng=.d52e4bbb-1e67-4ca8-8342-1809b2969218@github.com>
Message-ID: <O0Q8Oqbznf66sDhuaExW_dXun9o3MO10gACNW1iUU5c=.e1d9350d-2653-43d5-8960-d8467df4090c@github.com>

On Tue, 29 Oct 2024 23:05:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:
> 
>> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
>> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
>> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;
> 
> `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

Maybe, but I only see it twice, not sure we gain much. Also we save having to jump back and forth to see what total_cont_size() would actually account for.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:
> 
>> 1061:   unwind_frames();
>> 1062: 
>> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);
> 
> It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

The reason why this is added and later subtracted is because when allocating the stackChunk we need to account for all space needed, but when specifying how much space the vthread needs in the stack to allocate the frames we don't need to count _monitors_in_lockstack. I'd rather not group it with frame::metadata_words because these are logically different things. In fact, if we never subtract frame::metadata_words when setting max_thawing_size we should not need to account for it in thaw_size() (this is probably something we should clean up in the future). But for _monitors_in_lockstack we always need to subtract it to max_thawing_size.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:
> 
>> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
>> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
>> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)
> 
> So this means it's OK to over-estimate the size here?

Yes, this will be the space allocated in the stack by the vthread when thawing.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:
> 
>> 2060:   }
>> 2061: 
>> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);
> 
> Suggestion:
> 
>   f.next(SmallRegisterMap::instance(), true /* stop */);
> 
> This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:
> 
>> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
>> 2649:   } else {
>> 2650:     _stream.next(SmallRegisterMap::instance);
> 
> Suggestion:
> 
>     _stream.next(SmallRegisterMap::instance());

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823486049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823487296
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823488795
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636

From pchilanomate at openjdk.org  Wed Oct 30 22:44:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 22:44:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos in comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/aa682de2..0951dfe0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=20-21

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From dlong at openjdk.org  Wed Oct 30 23:05:48 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:05:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
 <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
Message-ID: <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>

On Tue, 29 Oct 2024 22:15:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/code/nmethod.cpp line 1302:
>> 
>>> 1300:     _compiler_type           = type;
>>> 1301:     _orig_pc_offset          = 0;
>>> 1302:     _num_stack_arg_slots     = 0;
>> 
>> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.
>
> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138

From pchilanomate at openjdk.org  Wed Oct 30 23:17:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 23:17:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
 <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
Message-ID: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>

On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
>> 
>>> 1409:     // zero out fields (but not the stack)
>>> 1410:     const size_t hs = oopDesc::header_size();
>>> 1411:     oopDesc::set_klass_gap(mem, 0);
>> 
>> Why, bug fix or cleanup?
>
> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580273

From dlong at openjdk.org  Wed Oct 30 23:17:54 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:17:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <gAguZ8-ByDjb8T7nqwPQp3yYwXtckYDHXq3GnO33Rl8=.f2f95768-d8e6-415f-8cba-b0aebd3a9ea6@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/objectMonitor.cpp line 1612:

> 1610: 
> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.

I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051

From dlong at openjdk.org  Wed Oct 30 23:25:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 30 Oct 2024 23:25:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
 <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
Message-ID: <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>

On Wed, 30 Oct 2024 22:11:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.hpp line 50:
>> 
>>> 48: class JavaThread;
>>> 49: 
>>> 50: // should match Continuation.PreemptStatus() in Continuation.java
>> 
>> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.
>
> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

Yes, that would be better for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967

From pchilanomate at openjdk.org  Wed Oct 30 23:25:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 30 Oct 2024 23:25:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <vUxHv6l3Fg7WdxvDoD8LDpIU2ROqR1knndtpMAIJxYE=.7ffc9144-af42-4258-8e9f-2afbf0f35c70@github.com>
Message-ID: <wiVrOwnsnXq1emrHePR9UMImJfRkHBhQPqjBzda9f4M=.cb038fea-540d-4e8d-884e-ac34cc4973d1@github.com>

On Wed, 30 Oct 2024 19:06:58 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add klass_name check for is_object_wait0
>>  - Fix comment in continuation.hpp
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:
> 
>> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
>> 2234:       if (!mon_acquired) {
>> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.
> 
> typo: acquire

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:
> 
>> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
>> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
>> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> typo: can be walked

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 334:
> 
>> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
>> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
>> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback
> 
> typo: Monitor **for** pending_contended_entered callback

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583906
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583954
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583822

From dlong at openjdk.org  Thu Oct 31 00:54:51 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 00:54:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:

> 187: 
> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));

If these accesses need to be atomic, could you add a comment explaining why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621

From dlong at openjdk.org  Thu Oct 31 01:01:53 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 01:01:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <FWssbuS1i62rs41m2kBR4A6kHiudXckVxVI6u6v91oM=.b3b499a5-fbe8-4939-8513-c9e58423582e@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/deoptimization.cpp line 125:

> 123: 
> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
> 125:   if (!nm->can_be_deoptimized()) {

Is this a performance optimization?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339

From dlong at openjdk.org  Thu Oct 31 01:34:53 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 01:34:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:

> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
> 43:   int64_t tid = thread->lock_id();
> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Should the "3" be a named constant with a comment?

src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:

> 205: }
> 206: 
> 207: inline bool ObjectMonitor::has_successor() {

Why are _succ accesses atomic here when previously they were not?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393

From iklam at openjdk.org  Thu Oct 31 02:09:31 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Oct 2024 02:09:31 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v5]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <T_mg1v5YnCQvpyEVw3XkEqQ2CNHvPARIwRMjdKAZwwE=.287b20fc-2462-45e9-99f4-e305b3b7d5a0@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with five additional commits since the last revision:

 - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity"
 - fixed comments
 - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked
 - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195
 - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/dd59b5f1..cd6cd6d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=03-04

  Stats: 301 lines in 16 files changed: 247 ins; 25 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From iklam at openjdk.org  Thu Oct 31 02:09:33 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Oct 2024 02:09:33 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <dQQmsawG5xpu_rrJmjGOfEs0LjV0gkYSqEBoTUXvU8M=.31d49b2e-1565-4fb0-b0b5-9ef82669ffe4@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
 <dQQmsawG5xpu_rrJmjGOfEs0LjV0gkYSqEBoTUXvU8M=.31d49b2e-1565-4fb0-b0b5-9ef82669ffe4@github.com>
Message-ID: <8Uo5XETPO-KOvj_NFbAgrQsF8F8V3s0Z37-UkxPH91g=.7bd3e72c-cec9-4eae-b17d-b113e5888c33@github.com>

On Fri, 25 Oct 2024 15:02:30 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8342907: Implement AOT testing mode for jtreg tests (authored by @katyapav)
>>  - disable test that fails with hotspot_runtime_non_cds_mode
>
> src/hotspot/share/cds/aotClassLinker.cpp line 117:
> 
>> 115: 
>> 116: void AOTClassLinker::add_candidate(InstanceKlass* ik) {
>> 117:   _candidates->put_when_absent(ik, true);
> 
> I just noticed the use of `put_when_absent` here. This means the caller should ensure that `ik` has not already been added to the `_candidates`. We do that currently (`try_add_candidate` calls `is_candidate` before calling `add_candidate`) but probably worth mentioning this contract explicitly in a comment somewhere for future readers.

I renamed it to `add_new_candidate()` and added comments so that it's clear what the contract is. I also added assert to check for thread safety.

> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 113:
> 
>> 111: 
>> 112:     if (CDSConfig::is_dumping_aot_linked_classes()) {
>> 113:       // Need to call try_add_candidate instead of is_candidate, as this may be called
> 
> I think in this version of the code this method is not used before `AOTClassLinker::add_candidates`. Can we switch back to `is_candidate` then?

In the future, these functions may be called before we enter the safepoint (e.g., to check if some constant pool entries can be resolved), so I think it's better to keep the `try_add_candidate()` call.

> src/hotspot/share/cds/heapShared.hpp line 298:
> 
>> 296:   static SeenObjectsTable *_seen_objects_table;
>> 297: 
>> 298:   // The "special subgraph" contains all the all archived objects that are reachable
> 
> an extra `all` in the comment

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1823682059
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1823684639
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1823684779

From iklam at openjdk.org  Thu Oct 31 02:11:33 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Oct 2024 02:11:33 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v4]
In-Reply-To: <OCEkuEHXdrRBIS0ZISo4ry8zhUadvIKnJtfSQ-9y3uI=.f6ba51e5-e28b-41a6-b60f-958d46b07660@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <epJus-sUQiyze8LsVhLYJNkStQqvPAfCD2MQQRwGAXY=.5a1bee84-5c99-443f-a30f-39fd6d05df66@github.com>
 <VR90kit4KTifPdSCey9s84rnO5qwy-qmVvT9XeDirZo=.7e56521c-a7a4-4d1b-803e-4f78da72b10b@github.com>
 <OCEkuEHXdrRBIS0ZISo4ry8zhUadvIKnJtfSQ-9y3uI=.f6ba51e5-e28b-41a6-b60f-958d46b07660@github.com>
Message-ID: <KX40DtMJUW_mSfr-0d8_j1JIoI1kwyqThyETImShB6U=.b041ddde-c380-41a0-b576-23f64ca4fb60@github.com>

On Fri, 25 Oct 2024 18:14:38 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionaryShared.cpp line 685:
>> 
>>> 683:     InstanceKlass* ik = InstanceKlass::cast(k);
>>> 684: 
>>> 685:     if (SafepointSynchronize::is_at_safepoint()) {
>> 
>> Why is this piece of block required?
>> It calls `is_excluded_class` which reads `DumpTimeClassInfo::_excluded` without checking for `has_checked_exclusion`. That means it can return false (the default value) even for classes that may later be marked for exclusion by `check_for_exclusion(ik, p)`.
>> <del>On the same note, I think we should add an assert in `DumpTimeClassInfo::is_excluded` that `has_checked_exclusion()` is true.<del>
>
> Does the check `SafepointSynchronize::is_at_safepoint` imply that exclusion checks for all classes have already been done?

I renamed the public function to `should_be_excluded(InstanceKlass*)` to avoid confusion with the private function `check_for_exclusion(InstanceKlass*, DumpTimeClassInfo*)`. I also added code to make sure that exclusion has been checked for the class, even when in safepoint.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1823688154

From iklam at openjdk.org  Thu Oct 31 02:23:24 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 31 Oct 2024 02:23:24 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v6]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed whitespace; fixed minimal build

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/cd6cd6d7..6eebd18f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From dholmes at openjdk.org  Thu Oct 31 02:29:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:29:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>

On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
> 
>> 205: }
>> 206: 
>> 207: inline bool ObjectMonitor::has_successor() {
> 
> Why are _succ accesses atomic here when previously they were not?

General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823698001

From dholmes at openjdk.org  Thu Oct 31 02:36:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 02:36:48 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <aynKsg_d9tERx3eWbwx9Pai29bRfYDjhTZJJ4ZzD5E8=.2bf3bb18-b265-49b6-ab51-42ac884f6e71@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
 <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
 <aynKsg_d9tERx3eWbwx9Pai29bRfYDjhTZJJ4ZzD5E8=.2bf3bb18-b265-49b6-ab51-42ac884f6e71@github.com>
Message-ID: <IIhS27BWERwqk0gopOo1NbCGrsUvZexWZxtOBmaLFSI=.5b65b8a3-c63b-4c3f-9994-ad0b4c7c904b@github.com>

On Wed, 30 Oct 2024 20:31:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address other cases in Hotspot
>
> Thank you for the review.

@justin-curtis-lu  for future reference note that hotspot generally requires two reviews per PR before integration. This was a very simple change but not "trivial" in the sense documented in the developer guide. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21724#issuecomment-2448900170

From dlong at openjdk.org  Thu Oct 31 02:36:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 02:36:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
Message-ID: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>

On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
>> 
>> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.
>
> The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:
> 
> 
>    0xffffdfdba584:	sub	sp, sp, #0x10
>    0xffffdfdba588:	stp	x29, x30, [sp]
>    0xffffdfdba58c:	ldrb	w8, [x28, #1192]
>    0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
>    0xffffdfdba594:	mov	x8, #0x4ba0                	
>    0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
>    0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5a0:	mov	x0, x28
>    0xffffdfdba5a4:	blr	x8
>    0xffffdfdba5a8:	mov	x9, sp
>    0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
>    0xffffdfdba5b0:	mov	x0, x1
>    0xffffdfdba5b4:	mov	x1, x2
>    0xffffdfdba5b8:	mov	x2, x28
>    0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
>    0xffffdfdba5c0:	mov	x8, #0xe6a4                	
>    0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
>    0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
>    0xffffdfdba5d0:	blr	x8
>    0xffffdfdba5d4:	nop
>    0xffffdfdba5d8:	movk	xzr, #0x0
>    0xffffdfdba5dc:	movk	xzr, #0x0
>    0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
>    0xffffdfdba5e4:	str	xzr, [x28, #1000]
>    0xffffdfdba5e8:	str	xzr, [x28, #1008]
>    0xffffdfdba5ec:	ldr	x10, [x28, #8]
>    0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
>    0xffffdfdba5f4:	ldp	x29, x30, [sp]
>    0xffffdfdba5f8:	add	sp, sp, #0x10
>    0xffffdfdba5fc:	ret
>    0xffffdfdba600:	ldp	x29, x30, [sp]
>    0xffffdfdba604:	add	sp, sp, #0x10
>    0xffffdfdba608:	adrp	x8, 0xffffdfc30000
>    0xffffdfdba60c:	add	x8, x8, #0x80
>    0xffffdfdba610:	br	x8

OK, so you're saying it's the stack adjustment that's the problem.  It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary.  Isn't that a bug that should be fixed?  I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest.  Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling.

It's still unclear to me exactly how we resume after preemption.  It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted.  If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment.  In your example, last_Java_pc would be set to 0xffffdfdba5e4.  I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823701666

From dlong at openjdk.org  Thu Oct 31 03:55:47 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 03:55:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java.  Is there a way to fix that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446

From dholmes at openjdk.org  Thu Oct 31 04:50:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 04:50:36 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation
In-Reply-To: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
Message-ID: <fgqmBO0FivxYJymOqiglCpk01yQLHt8KrHtdKkts3Ww=.d1177656-f9e8-48a0-beb6-89e0e78d08ef@github.com>

On Mon, 28 Oct 2024 08:34:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
> 
> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
> 
> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
> 
> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

Hotspot cleanup looks great! It is really good to see this temporary transition logic go away.

src/java.base/share/classes/java/lang/ThreadLocal.java line 813:

> 811: 
> 812:     /**
> 813:      * Print the print stack of the current thread, skipping the printStackTrace frame.

Suggestion:

     * Print the stack of the current thread, skipping the printStackTrace frame.

src/java.base/share/classes/java/lang/VirtualThread.java line 537:

> 535:                 assert parkTimeout > 0;
> 536:                 timeoutTask = schedule(this::unpark, parkTimeout, NANOSECONDS);
> 537:                 setState(newState = TIMED_PARKED);

Just to be clear here, if the timeout expires before we can call `setState`, the unpark is basically a no-op, and we will see that we have been unparked at line 541 and set the state correctly to UNPARKED.

test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java line 93:

> 91:             } finally {
> 92:                 // ExecutorService::execute may consume parking permit
> 93:                 LockSupport.unpark(Thread.currentThread());

This seems a bit odd - why would the current thread need to unpark itself? Why should it have a park permit available here?

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21735#pullrequestreview-2406915529
PR Review Comment: https://git.openjdk.org/jdk/pull/21735#discussion_r1823761637
PR Review Comment: https://git.openjdk.org/jdk/pull/21735#discussion_r1823766067
PR Review Comment: https://git.openjdk.org/jdk/pull/21735#discussion_r1823767061

From alanb at openjdk.org  Thu Oct 31 06:54:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 06:54:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <NfRdSZPUwU4q6AUukmgsV6BFGCMnpaR4er2MXw9HcXA=.4103e369-ae6d-44d5-8a01-4d8c61f5ca36@github.com>
Message-ID: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.cea2b3e3-caa3-4629-8bcc-82f33ae61971@github.com>

On Thu, 31 Oct 2024 03:52:31 GMT, Dean Long <dlong at openjdk.org> wrote:

> For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that?

I don't think which view this is but just to say that VirtualThreadPinnedEvent.java and libTracePinnedThreads.c are removed. libSynchronizedNative.c is part of a new test (as it happens, it was previously reviewed as pull/18600 but we had to hold it back as it needed a fix from the loom repo that is part of the JEP 491 implementation). You find is easier to just fetch and checkout the branch to look at the changes locally. Personally I have this easier for large change and makes it easier to see renames and/or removals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774

From jwaters at openjdk.org  Thu Oct 31 07:18:35 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 31 Oct 2024 07:18:35 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>

> 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 incrementally with one additional commit since the last revision:

  Remove global memHandle, would've liked to keep it as a comment :(

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/cd57fc6c..4d15fe78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From jwaters at openjdk.org  Thu Oct 31 07:18:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 31 Oct 2024 07:18:38 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
 <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
Message-ID: <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>

On Sat, 26 Oct 2024 04:35:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem

I'll also start looking into this in the meantime, unless you explicitly want me not to do so

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2449178499

From jwaters at openjdk.org  Thu Oct 31 07:18:43 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 31 Oct 2024 07:18:43 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v3]
In-Reply-To: <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
Message-ID: <sMtxDsrNf6iclpJ1z-mQ47IiZlnIhz566uvgUBC2yFo=.3dfe0353-52c5-43a6-8193-38a0ba0e6b76@github.com>

On Sun, 27 Oct 2024 06:25:02 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into unused
>  - 8342682

Also, core-libs, any comment on jpackage?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2449178848

From jwaters at openjdk.org  Thu Oct 31 07:18:47 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 31 Oct 2024 07:18:47 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v3]
In-Reply-To: <aA_T7_v8bpkOiXMGJqGoUZwpGuh9c4Yerz2eTzHyhqw=.d011b331-9f69-4429-9991-53d7116892c5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <wY9qe0_vTOymuAYaCR3UKVvDb-067-WJbr8EZZeakbs=.778984b0-150a-41c9-a1ba-79c1f01a3985@github.com>
 <aA_T7_v8bpkOiXMGJqGoUZwpGuh9c4Yerz2eTzHyhqw=.d011b331-9f69-4429-9991-53d7116892c5@github.com>
Message-ID: <Zdk00eHx7cwHHdDBSxp4T94ZF3SED89lWX6l0lYFVIc=.62c04ec4-9909-4c07-990b-73d8238ec5d5@github.com>

On Wed, 30 Oct 2024 06:27:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unused
>>  - 8342682
>
> src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c line 40:
> 
>> 38:  */
>> 39: 
>> 40: // static HANDLE memHandle = NULL;
> 
> I still think this should be removed instead of commented out.

I was more fond of keeping it as a comment, but oh well. Give me a moment...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1823903506

From alanb at openjdk.org  Thu Oct 31 07:19:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 07:19:10 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation [v2]
In-Reply-To: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
Message-ID: <MX3y_XSYKnGhQ5CKN1VkGnHOrRY4waaCitHHP9Soq5A=.b06cd776-785b-4967-a16d-5d95fdc6641c@github.com>

> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
> 
> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
> 
> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
> 
> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

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 four additional commits since the last revision:

 - Fix typo in comment
 - Merge branch 'master' into JDK-8343132
 - Merge branch 'master' into JDK-8343132
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21735/files
  - new: https://git.openjdk.org/jdk/pull/21735/files/c88ce3dd..2d18c116

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21735&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21735&range=00-01

  Stats: 54557 lines in 1036 files changed: 11998 ins; 40288 del; 2271 mod
  Patch: https://git.openjdk.org/jdk/pull/21735.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21735/head:pull/21735

PR: https://git.openjdk.org/jdk/pull/21735

From alanb at openjdk.org  Thu Oct 31 07:19:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 07:19:11 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation [v2]
In-Reply-To: <fgqmBO0FivxYJymOqiglCpk01yQLHt8KrHtdKkts3Ww=.d1177656-f9e8-48a0-beb6-89e0e78d08ef@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
 <fgqmBO0FivxYJymOqiglCpk01yQLHt8KrHtdKkts3Ww=.d1177656-f9e8-48a0-beb6-89e0e78d08ef@github.com>
Message-ID: <cf2SKRwfj_0Qsa_OuafyXm_l-geORF5H4l-EaPV_cZM=.fb06f696-3462-4231-bc88-634cefa29c31@github.com>

On Thu, 31 Oct 2024 04:43:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 four additional commits since the last revision:
>> 
>>  - Fix typo in comment
>>  - Merge branch 'master' into JDK-8343132
>>  - Merge branch 'master' into JDK-8343132
>>  - Initial commit
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 537:
> 
>> 535:                 assert parkTimeout > 0;
>> 536:                 timeoutTask = schedule(this::unpark, parkTimeout, NANOSECONDS);
>> 537:                 setState(newState = TIMED_PARKED);
> 
> Just to be clear here, if the timeout expires before we can call `setState`, the unpark is basically a no-op, and we will see that we have been unparked at line 541 and set the state correctly to UNPARKED.

Yes, and same thing is unparked by some other thread while the target thread is parking. We have several tests that bash on this.

> test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java line 93:
> 
>> 91:             } finally {
>> 92:                 // ExecutorService::execute may consume parking permit
>> 93:                 LockSupport.unpark(Thread.currentThread());
> 
> This seems a bit odd - why would the current thread need to unpark itself? Why should it have a park permit available here?

In this test, Scheduler.execute method will consume the current thread's parking permit when there is contention on the queue. In a well behaved system, all usages of park will first test some condition before parking. This test doesn't do this, hence it created the scenario where parking after unparking might hang. Previous discussion in [loom/pull/59](https://github.com/openjdk/loom/pull/59). There is no support exposed for doing custom schedulers at this time but this is the type of thing that comes up so we kept the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21735#discussion_r1823905112
PR Review Comment: https://git.openjdk.org/jdk/pull/21735#discussion_r1823903551

From dholmes at openjdk.org  Thu Oct 31 08:48:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 31 Oct 2024 08:48:29 GMT
Subject: RFR: 8343132: Remove temporary transitions from Virtual thread
 implementation [v2]
In-Reply-To: <MX3y_XSYKnGhQ5CKN1VkGnHOrRY4waaCitHHP9Soq5A=.b06cd776-785b-4967-a16d-5d95fdc6641c@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
 <MX3y_XSYKnGhQ5CKN1VkGnHOrRY4waaCitHHP9Soq5A=.b06cd776-785b-4967-a16d-5d95fdc6641c@github.com>
Message-ID: <lICgfSbIQyy0hOWBqRopfS310PsbbMp0re8nq9zGQOk=.f718cde2-8dae-42ba-af09-8fd7fbc9173d@github.com>

On Thu, 31 Oct 2024 07:19:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
>> 
>> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
>> 
>> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
>> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
>> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
>> 
>> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.
>
> 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 four additional commits since the last revision:
> 
>  - Fix typo in comment
>  - Merge branch 'master' into JDK-8343132
>  - Merge branch 'master' into JDK-8343132
>  - Initial commit

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21735#pullrequestreview-2407378053

From alanb at openjdk.org  Thu Oct 31 08:56:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 08:56:32 GMT
Subject: Integrated: 8343132: Remove temporary transitions from Virtual thread
 implementation
In-Reply-To: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
References: <i7nm02p0Lt3JZe-4nLPCSdq3GaBzHRdMXVRj7htpKqY=.2ed3f6cd-8b2f-452f-85a5-223ab169eae7@github.com>
Message-ID: <5j95fxB8FMoMOxC05wv_Cbq5gK6sMjnAuZKkluKuq2I=.854d967b-98e5-4631-90cb-38713aac86c7@github.com>

On Mon, 28 Oct 2024 08:34:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is an update to the Virtual thread implementation that we'd like to integrate in advance of JEP 491.
> 
> The update removes the use of  "temporary transitions", basically cases where the thread identity switches to the carrier thread to do something in the context of the carrier while a virtual thread is mounted. These cases create complexity for JVMTI and observability tools. It has also attracted attention in the review of the JEP 491 implementation as the object monitor changes have to deal with the possibility of entering monitors while in this state. There are 3 usages changes:
> 
> 1. In submitRunContinuation the submit to the scheduler is changed so that it executes in the context of a virtual thread for cases where one virtual thread unparks another. This requires pinning to prevent preemption during this sensitive operation. ForkJoinPool.poolSubmit is changed so that it uses the identity of the carrier. This change has no impact on the uses of lazySubmit or externalSubmit.
> 2. Timed-park. The current implementation schedules/cancels the timer task with the virtual thread mounted. This runs in the context of the carrier as any contention would infer with thread state, park blocker and the parking permit. The implementation is changed to schedule the timeout after unmounting, and to cancel before re-mounting. The downside of this is that it will scheduled later (maybe 200us later than before). We could capture the time and adjust but it doesn't seem worth it.
> 3. jdk.tracePinnedThreads. This is a diagnostic option for finding usages of thread locals in code executed by virtual threads. This is changed so use a thread local to detect reentrancy.
> 
> The changes means that notifyJvmtiHideFrames, its intrinsic, and the JVMTI "tmp VTMS_transition" bit go away.

This pull request has now been integrated.

Changeset: dee0982c
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dee0982c603b389148a2e615c10c1276c3c589ae
Stats:     354 lines in 16 files changed: 91 ins; 170 del; 93 mod

8343132: Remove temporary transitions from Virtual thread implementation

Reviewed-by: dholmes, sspitsyn, pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/21735

From stuefe at openjdk.org  Thu Oct 31 09:05:36 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Oct 2024 09:05:36 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <ZsvPkEmZCV0EtfP4DvSqXh06k0gufPDoVnQZalXM_9U=.cf9788dc-fa2e-4581-ba1d-53517f712504@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
 <ZsvPkEmZCV0EtfP4DvSqXh06k0gufPDoVnQZalXM_9U=.cf9788dc-fa2e-4581-ba1d-53517f712504@github.com>
Message-ID: <YfsMmbC_w51hOHvtkkZlMSHC36of7n1F77415O0rxrM=.6a7e928a-623f-4182-9495-c3db56db6c55@github.com>

On Wed, 30 Oct 2024 15:57:57 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> So that means we'd need to have both ThreadCritical and NmtVirtualMemory_lock in that method (if we were to do the other replacements). One to protect the chunks and one to protect the malloc accounting. It might also be good to rename NmtVirtualMemory_lock then too.

Please split this code in two parts. First part removes retired chunks from the arena chunk list and adds them to a new temporary list. Second part goes through the temp list and deletes the chunks. First part under ThreadCritical, second part under `NmtVirtualMemory_lock`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2449366080

From sgehwolf at openjdk.org  Thu Oct 31 09:17:40 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 31 Oct 2024 09:17:40 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v11]
In-Reply-To: <64ooaT_1G3AIl9kLn2ms8Q4GoNLequhhcD05LIETN3g=.449e4916-2770-48f6-b5a8-aa07d6ffeab6@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <64ooaT_1G3AIl9kLn2ms8Q4GoNLequhhcD05LIETN3g=.449e4916-2770-48f6-b5a8-aa07d6ffeab6@github.com>
Message-ID: <UrdeRB7JowWpRiyb69YvxlH_eM1Lt2P57dPrNDN5xYc=.9e121eb0-8810-4088-b3e6-71a6d6fbc4b3@github.com>

On Tue, 22 Oct 2024 14:18:50 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 36 commits:
> 
>  - 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
>  - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8322420_cgroup_hierarchy_walk_init
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/2da7f2bc...a3989e80

Still looking for a reviewer for this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2449386120

From sspitsyn at openjdk.org  Thu Oct 31 09:25:51 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 31 Oct 2024 09:25:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <Foq1XXp9yZ1FQxckc764CmDDyEm_uqnshCs9frltjIg=.14ae967b-c997-467e-99b2-655a1344b355@github.com>
 <3D3jZxTAteqXG6m198psH56qwFU5rQsSiyLdcwSaIRc=.895587cf-3048-44dc-a9b9-aa31b905ca7d@github.com>
Message-ID: <FKZnn7aT8nPcZxjsPU2a96efMUA2BkOBGXQhZ4KIlR4=.bbb34e06-c0ac-4544-986f-ca2680fed2e1@github.com>

On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 88:
>> 
>>> 86:       if (_target->has_async_exception_condition()) {
>>> 87:         _failed = true;
>>> 88:       }
>> 
>> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.
>
> These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

Just wanted to understand what needs to be checked after the start_VTMS_transition() call.
You are right, we need to check the `_thread->has_async_exception_condition()` after the call.
The pending `popframe` and  `earlyret` can be checked before as I understand.
I'm not sure there is a real need in double-checking before and after. So, let's keep it as it is for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824134075

From stuefe at openjdk.org  Thu Oct 31 10:55:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Oct 2024 10:55:37 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <7EREZErHKW77dnrPaT8vK_gO12fvHfCmwkqQ140xfvQ=.f5c865d7-3ef4-4c7b-9785-3be7ba4dc9e0@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

I had to analyze this again, to understand why we need this locking, since my mind slips.

I updated my findings in https://bugs.openjdk.org/browse/JDK-8325890 . Please see details there.

But I don't think the current locking makes much sense, tbh (even before this patch). Or I don't get it.

We have three counters in play here:
A) the `malloc[mtChunk]` malloc counter for the mtChunk tag
B) the global malloc counter
C) the `arena[xxx]` arena counter for the mtXXX tag the arena is tagged with

Upon arena growth, we incremement all four. In two steps - first (A) and (B) under os::malloc, then (C) in the arena code. 

Upon arena death, we may delete the chunk, in which case we adjust all three counters as well.

But since we don't want (B) to include arena sizes, we have several places where we lazily adjust (B) and (A) from the sum of all arena counters (see JBS issue). These adjustments must be synchronized with arena allocations. But we don't do this. The lock does not include (C). For that, the lock would have to be at a different place, inside arena code. We only lock around (A) and (B).

I am not sure what the point of this whole thing is. I am also not convinced that it always works correctly. This whole "updating counters lazily" business makes the code brittle.

Also, the current locking does not guarantee correctness anyway. There are several places in the coding where we calculate e.g. the sum of all mallocs, but malloc counters are modified (rightly so) out of lock protection.

To make matters even more complex, we have not two locks here but three:
- ThreadCritical
- the new `NmtVirtualMemory_lock`
- we also have the `NMTQuery_lock`, which guards NMT reports from jcmd exclusively

Not sure what the point of the latter even is. It certainly does not prevent us from getting reports while underlying data structures are being changed, unless I am overlooking something.

It would be very nice if someone other than me could analyze this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2449568622

From jsjolen at openjdk.org  Thu Oct 31 11:13:36 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 31 Oct 2024 11:13:36 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <7EREZErHKW77dnrPaT8vK_gO12fvHfCmwkqQ140xfvQ=.f5c865d7-3ef4-4c7b-9785-3be7ba4dc9e0@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
 <7EREZErHKW77dnrPaT8vK_gO12fvHfCmwkqQ140xfvQ=.f5c865d7-3ef4-4c7b-9785-3be7ba4dc9e0@github.com>
Message-ID: <FgARKkGS_MVCdZtB8XF6xniRb7QR_erGAHjrb31M9PA=.8a9fe78e-2357-4c87-af44-69e42d64c110@github.com>

On Thu, 31 Oct 2024 10:53:12 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I had to analyze this again, to understand why we need this locking, since my mind slips.
> 
> I updated my findings in https://bugs.openjdk.org/browse/JDK-8325890 . Please see details there.
> 
> But I don't think the current locking makes much sense, tbh (even before this patch). Or I don't get it.
> 
> We have three counters in play here: A) the `malloc[mtChunk]` malloc counter for the mtChunk tag B) the global malloc counter C) the `arena[xxx]` arena counter for the mtXXX tag the arena is tagged with
> 
> Upon arena growth, we incremement all four. In two steps - first (A) and (B) under os::malloc, then (C) in the arena code.
> 
> Upon arena death, we may delete the chunk, in which case we adjust all three counters as well.
> 
> But since we don't want (B) to include arena sizes, we have several places where we lazily adjust (B) and (A) from the sum of all arena counters (see JBS issue). These adjustments must be synchronized with arena allocations. But we don't do this. The lock does not include (C). For that, the lock would have to be at a different place, inside arena code. We only lock around (A) and (B).
> 
> I am not sure what the point of this whole thing is. I am also not convinced that it always works correctly. This whole "updating counters lazily" business makes the code brittle.
> 
> Also, the current locking does not guarantee correctness anyway. There are several places in the coding where we calculate e.g. the sum of all mallocs, but malloc counters are modified (rightly so) out of lock protection.
> 
> To make matters even more complex, we have not two locks here but three:
> 
>     * ThreadCritical
> 
>     * the new `NmtVirtualMemory_lock`
> 
>     * we also have the `NMTQuery_lock`, which guards NMT reports from jcmd exclusively
> 
> 
> Not sure what the point of the latter even is. It certainly does not prevent us from getting reports while underlying data structures are being changed, unless I am overlooking something.
> 
> It would be very nice if someone other than me could analyze this.

If this is so brittle and complex, then I wonder what you even get out of us doing the `ThreadCritical` trick. In other words, if we just removed it, would anyone notice and be able to discern what's occurred? Open question, I might do that change and run the tests on it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2449601108

From kevinw at openjdk.org  Thu Oct 31 12:17:41 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 31 Oct 2024 12:17:41 GMT
Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not
 cause test failure
Message-ID: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com>

Test update: fail when it hits an Exception.

This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this.
I am working on http, so we may revisit these tests in future to change their list of protocols.

For now, I'd like to simply make this test fail if any of the protocols it tests have failures.
Fix a few typos while we are here.

-------------

Commit messages:
 - 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure

Changes: https://git.openjdk.org/jdk/pull/21804/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343378
  Stats: 11 lines in 1 file changed: 4 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21804/head:pull/21804

PR: https://git.openjdk.org/jdk/pull/21804

From stuefe at openjdk.org  Thu Oct 31 12:37:46 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Oct 2024 12:37:46 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <FgARKkGS_MVCdZtB8XF6xniRb7QR_erGAHjrb31M9PA=.8a9fe78e-2357-4c87-af44-69e42d64c110@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
 <7EREZErHKW77dnrPaT8vK_gO12fvHfCmwkqQ140xfvQ=.f5c865d7-3ef4-4c7b-9785-3be7ba4dc9e0@github.com>
 <FgARKkGS_MVCdZtB8XF6xniRb7QR_erGAHjrb31M9PA=.8a9fe78e-2357-4c87-af44-69e42d64c110@github.com>
Message-ID: <1Xim6wW0FyJR3prCti1N3p9rwnL9-I67L947q4i7100=.3fe0d041-fefd-498d-a359-adf4d30d32e9@github.com>

On Thu, 31 Oct 2024 11:11:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> If this is so brittle and complex, then I wonder what you even get out of us doing the ThreadCritical trick. In other words, if we just removed it, would anyone notice and be able to discern what's occurred? Open question, I might do that change and run the tests on it.

@jdksjolen good question. I am not sure who introduced that, may have been Afshin as a fix for some NMT test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2449740884

From kevinw at openjdk.org  Thu Oct 31 12:47:32 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 31 Oct 2024 12:47:32 GMT
Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2]
In-Reply-To: <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
 <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
Message-ID: <fmkwTM41uAUCLaJGw-ebPZTk4ea1PqAXbZn3L9_EOy4=.a04aa820-6fba-4f01-806c-df36649df304@github.com>

On Tue, 10 Sep 2024 15:42:57 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
>
> Sonia Zaldana Calles 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8204681
>  - 8204681: Option to include timestamp in hprof filename

A few notes, without reviewing the code further today, see if these all make sense and are settled:

"%t" expanded to timestamp seems simple enough (I think % is not controversial, extending from our existing use of %p)


But yes what is a timestamp?  There could be debate on the format.
The original issue came from a user request, but it was not fully specified, just a request for an automatic way of putting file creation time in an output filename.

So should we have %t and %d ? Or adopt all the decorator options from unified logging?  To me those seem extreme: if I just want output files to say when they were made, I don't really need options, or nanoseconds, and would be quite happy with the ostream.cpp style of "%t => YYYY-MM-DD_HH-MM-SS".


Sonia your points above:
(I haven't looked in detail at how this affects copy_expand_arguments, but if we can settle the jcmd options then that can follow...)

1. -filepattern
Would really like to avoid adding a new jcmd option, in all the diagnostic commands that take an output filename, and just go with a filename that respects some substitutions.

2
%t and %p are "unique enough" that we don't need "%TIMESTAMP" ?
We don't need to permit creating "my%perfect%test%file" without using "%%" to get a literal % included?

3.
-XX:+AllowFileNamePattern 
I would think at this step, we get our jcmds that take an output FILE to respect the %t timestamp.  There may be other XX options that take filenames which could be considered in future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2449759987

From stuefe at openjdk.org  Thu Oct 31 13:35:29 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 31 Oct 2024 13:35:29 GMT
Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2]
In-Reply-To: <fmkwTM41uAUCLaJGw-ebPZTk4ea1PqAXbZn3L9_EOy4=.a04aa820-6fba-4f01-806c-df36649df304@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
 <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
 <fmkwTM41uAUCLaJGw-ebPZTk4ea1PqAXbZn3L9_EOy4=.a04aa820-6fba-4f01-806c-df36649df304@github.com>
Message-ID: <1RTpmldd-3KiweJKXqWIBU76-qTZsL_3-QgDB1L7PqM=.aeefb5cd-b4bd-4a02-b8b3-f3d5cb286d14@github.com>

On Thu, 31 Oct 2024 12:45:07 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> So should we have %t and %d ? Or adopt all the decorator options from unified logging? To me those seem extreme: if I just want output files to say when they were made, I don't really need options, or nanoseconds, and would be quite happy with the ostream.cpp style of "%t => YYYY-MM-DD_HH-MM-SS".

A subset of the decorators of UL would make perfect sense, especially if we talk about a (possibly future) generic way to enrich file names:
- time (t),  utctime (UTC)  make obviously sense
- uptime (u), ... possibly (eg as a primitive way to avoid duplication for multiple dumped files in one run)
- hostname makes a lot of sense for distributed systems
- pid obvious
- tid possibly, if one has the need to dump per-thread files

I would argue for reusing these specifiers, and (either now or in the future) possibly also the code behind them, for decorating file names. Better than having to come up today with a %t, tomorrow someone maybe needs the hostname too, so %h? and so on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2449854403

From schernyshev at openjdk.org  Thu Oct 31 15:04:57 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 31 Oct 2024 15:04:57 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
Message-ID: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@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


However, if Java runs in a container, `/proc/self/cgroup` and `/proc/self/mountinfo` are mapped (read-only) from host, because docker uses `--cgroupns=host` by default in cgroup v1 hosts. Then `_root` and `cgroup_path` belong to the host and do not exist in the container. In containers Java must fall back to `_mount_point` of the corresponding cgroup controller.

When `--cgroupns=private` is used, `_root` and `cgroup_path` are always equal to `/`.

In hosts, the `cgroup_path` should always be added to the mount point, no matter how it compares to the `_root`.

The patch uses the result of `is_containerized()` to select the correct path. It is suggested to change the semantics of `is_read_only()` so that it returns the combined read-only flag for all mounted controllers. Currently the only usage of `_read_only` flag is to determine that V1 subsystem `is_containerized()`. `_read_only` flags are available in advance, before initialization of any CgroupV1SubsystemController objects.

The Java side is updated to follow the same logic.

-------------

Commit messages:
 - 8343191: Cgroup v1 subsystem fails to set subsystem path

Changes: https://git.openjdk.org/jdk/pull/21808/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343191
  Stats: 229 lines in 10 files changed: 157 ins; 30 del; 42 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 kevinw at openjdk.org  Thu Oct 31 15:17:37 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 31 Oct 2024 15:17:37 GMT
Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2]
In-Reply-To: <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
 <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
Message-ID: <GRuMyl7bZO-A8OsOuHC3dUV0V2Hg3jOtmdrHQ59MK6M=.265d3e74-4076-40fc-a5ab-caba0ee4d4fa@github.com>

On Tue, 10 Sep 2024 15:42:57 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
>
> Sonia Zaldana Calles 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8204681
>  - 8204681: Option to include timestamp in hprof filename

Thanks Thomas -
Good to get this going again 8-)

Not really against other substitutions being available if somebody is going to implement them. 8-)
(and explore the possible code sharing)

Timestamp is valuable as it's a commonly needed and hard to know ahead of time.
It seems useful that we do it in the JVM, as while I can call out to `date +%...` in a terminal or in a script, I have to think a fair amount (and generate a date string in a consistent way, and without spaces and slashes).


Can't see a problem with %h hostname being added later if there is a perceived need, if this change goes ahead just doing timetamps.

I was thinking about the changes being possible incrementally, but much seems to depend on how much work the author wants to take on at once.


For parsing a filename in a command, one-letter identifiers like %p, %t, and maybe %h etc... are unambiguous to parse.

Using the unified logging decorator set, we start using two characters or more. Things get ambiguous if we don't terminate the parsing somehow, and the user has to say something like "filename%(t)issue123.out" if they don't separate things with non alphabetic characters, e.g. "filename_%t_issue123.out".  I might prefer the latter, but not sure I can say everybody has to do it that way...



Now I reread the original issue:
8204681: Option to include timestamp in hprof filename
..so that was raised about -XX:HeapDumpOnOutOfMemoryError etc...

If this change is to add %t timestamp (or more) in jcmd output files, it should all be in a new issue like "Option to include timestamp in jcmd output filenames", and in future -XX:HeapDumpOnOutOfMemoryError etc could still be expanded to respect a timestamp etc... with 8204681.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2450140586

From sgehwolf at openjdk.org  Thu Oct 31 15:57:35 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 31 Oct 2024 15:57:35 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <HjEfFy6o5bZ8pMKliZThM8IZD_XKyw2xwTmdOzXQ-SM=.5e6c1c26-556c-4fa5-b906-5507674b1142@github.com>

On Thu, 31 Oct 2024 15:00:25 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 to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

What testing have you done? Did you run existing container tests in:


test/jdk/jdk/internal/platform
test/hotspot/jtreg/containers


As far as I can tell this breaks privileged container runs. I.e. `docker run --privileged --memory 400m --memory-swap 400m ... /opt/jdk/bin/java -Xlog:os+container=trace` wouldn't pick up the `400m` container limit on CG v1?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2450233596

From rriggs at openjdk.org  Thu Oct 31 15:58:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 31 Oct 2024 15:58:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <y-jccaVTuCdisVPbN2qCr2rVn8tCHNLThqd75t2crl0=.7c7a4790-5327-4925-9153-e591cfee552d@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408378244

From mchung at openjdk.org  Thu Oct 31 16:11:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 31 Oct 2024 16:11:04 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <T5ERS9U-Z-8BFoRNUpGqJnmRkP6FQc8DEX7qbXqODVU=.6f3e8f2f-de82-48c0-a8ee-c935093e825a@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2408431117

From fbredberg at openjdk.org  Thu Oct 31 16:18:57 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 16:18:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v19]
In-Reply-To: <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.1b330f87-a4d3-4b20-b6ac-1aa45a5a19b5@github.com>

On Wed, 30 Oct 2024 00:44:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add klass_name check for is_object_wait0
>  - Fix comment in continuation.hpp

Been learning a ton by reading the code changes and questions/answers from/to others.
But I still have some questions (and some small suggestions).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418

From fbredberg at openjdk.org  Thu Oct 31 16:18:59 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 16:18:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
Message-ID: <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>

On Thu, 24 Oct 2024 21:08:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>  - Fix comments in javaThread.hpp and Thread.java
>  - Rename nonce/nounce to seqNo in VirtualThread class
>  - Remove ObjectMonitor::set_owner_from_BasicLock()

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:

> 943: 
> 944:   void inc_held_monitor_count();
> 945:   void dec_held_monitor_count();

I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 

Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:

> 738: void MacroAssembler::clobber_nonvolatile_registers() {
> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
> 740:   Register regs[] = {

Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
Suggestion:

  static const Register regs[] = {

src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:

> 271:         ? frame_sp + fsize - frame::sender_sp_offset
> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
> 273:         : *(intptr_t**)(hf.sp() - 2);

Suggestion:

        : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:

> 791: 
> 792:   void inc_held_monitor_count(Register tmp = t0);
> 793:   void dec_held_monitor_count(Register tmp = t0);

I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/share/runtime/continuation.cpp line 125:

> 123: };
> 124: 
> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
Suggestion:

static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.cpp line 135:

> 133: #endif // INCLUDE_JVMTI
> 134: 
> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread`.
Suggestion:

static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.hpp line 66:

> 64: 
> 65:   enum preempt_kind {
> 66:     freeze_on_monitorenter = 1,

Is there a reason why the first enumerator doesn't start at zero?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:

> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
> 888:   } else {
> 889:     return freeze_pinned_native;

Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

src/hotspot/share/runtime/objectMonitor.cpp line 1193:

> 1191:   }
> 1192: 
> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");

In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822551094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822696920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822200193
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822537887
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824253403
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824255622
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824262945
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824405820
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824676122

From pchilanomate at openjdk.org  Thu Oct 31 16:27:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:27:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v23]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <xv2amcWDXc_uGB2S2DZoiWZbJ3qppSMtkrAmJCNZtd0=.402be468-c406-4fd1-a7c9-cedbb6b53e7a@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Add ObjectMonitor::successor() method + use ThreadIdentifier::initial()
 - Comments for Dean

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/0951dfe0..9f086c52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=21-22

  Stats: 13 lines in 5 files changed: 6 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From jlu at openjdk.org  Thu Oct 31 16:30:32 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Oct 2024 16:30:32 GMT
Subject: RFR: 8341788: Fix ExceptionOccurred in hotspot [v2]
In-Reply-To: <IIhS27BWERwqk0gopOo1NbCGrsUvZexWZxtOBmaLFSI=.5b65b8a3-c63b-4c3f-9994-ad0b4c7c904b@github.com>
References: <t9KsGC1wk-W58pJuXOVMvE8pdepeO8eFTSWMfvFiD8A=.53add17b-2497-47c3-8a15-60f479806b17@github.com>
 <sORAOSHAad0QEKxUO3uMVUXWVxbHyPaLZ_HZnihURys=.33652438-9565-43e4-9430-836c6d1745a8@github.com>
 <aynKsg_d9tERx3eWbwx9Pai29bRfYDjhTZJJ4ZzD5E8=.2bf3bb18-b265-49b6-ab51-42ac884f6e71@github.com>
 <IIhS27BWERwqk0gopOo1NbCGrsUvZexWZxtOBmaLFSI=.5b65b8a3-c63b-4c3f-9994-ad0b4c7c904b@github.com>
Message-ID: <eX8bRZyooFW0w9dpYji4ysJzFxTIODokkUQK79oiDTM=.e50bcc40-6587-4378-a207-dfefffb6dfbf@github.com>

On Thu, 31 Oct 2024 02:34:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thank you for the review.
>
> @justin-curtis-lu  for future reference note that hotspot generally requires two reviews per PR before integration. This was a very simple change but not "trivial" in the sense documented in the developer guide. Thanks.

@dholmes-ora understood, thanks for the heads up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21724#issuecomment-2450308613

From pchilanomate at openjdk.org  Thu Oct 31 16:38:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v17]
In-Reply-To: <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <vq_CeJkZd5R_MCxKjcV2mAp2hDjLGaCrlfBZy0Tr-T4=.dd2524bc-7cfd-4485-8df8-b6986120ba61@github.com>
 <VHVe1VITZ8RwM4zCY6H3aq_NE6lUrpYpUKehbxSrVDo=.1fb44f60-38a1-4347-8a89-723fe71bd992@github.com>
 <Vlm5gFY0u-WunA1A4Z1EcM0ybXFxfKSn4VqBNHw8jr4=.514f054b-1fc8-463f-9437-8417948247bc@github.com>
 <EYqjmbQIGTk6B06gDOoyk5vhOYqHAqwZWJKlk-CE540=.f6de96ba-8f01-4354-afb0-8332ea32d443@github.com>
Message-ID: <DyT3JlQrGtqeWtycBFv1OKjZmtAyW3nw2G0_AGrx-s8=.1985fddd-fa5f-4c43-9b11-3adb18b4e6a9@github.com>

On Wed, 30 Oct 2024 23:02:28 GMT, Dean Long <dlong at openjdk.org> wrote:

>> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.
>
> Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565

From pchilanomate at openjdk.org  Thu Oct 31 16:38:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
Message-ID: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>

On Thu, 31 Oct 2024 02:33:30 GMT, Dean Long <dlong at openjdk.org> wrote:

> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>
It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824782389

From pchilanomate at openjdk.org  Thu Oct 31 16:38:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v23]
In-Reply-To: <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2Ev29hUuiTmOubia29XtacFVg4K0I76PwIREDCkJCxg=.c9fdce95-1960-4a09-a3d2-83fefeb58528@github.com>
 <wbcgbmaWVSQ-BXFNIt6PF6iUYLxMtOXJsol3vKtonpI=.bd275b29-651a-487a-a47f-0b7293e0be7b@github.com>
 <EqzJwgxYAcRVIiZzakj9qQvh9Y7YkavFQClDCK7XYMk=.665f5de1-15d8-44ec-8c02-4f935f0bdd64@github.com>
 <ITkQbnwRpdQEDrDUS19FCNkQLmgr7qmt4K_c4rwMcB4=.5a217806-90f9-439e-9f3c-5d21b7bda0b8@github.com>
Message-ID: <RyqfC0X-r4X4nNHdq40aKJr0RnQyUR9Qcuckmcrcpc8=.380fcc65-f9b7-4d81-99ad-3187d2f612cd@github.com>

On Wed, 30 Oct 2024 23:22:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.
>
> Yes, that would be better for now.

Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898

From pchilanomate at openjdk.org  Thu Oct 31 16:38:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <0pzLwKtFTJr3TkMvwhTizbkSaub4VbYvk85UTc0Na4k=.26700b04-b650-43a2-8f24-432737b37235@github.com>
Message-ID: <sIrGvDJcWMOXud3JGT-dpBAZ6CVMn6zp7tkTct0qay0=.91d48ee7-25d3-46ba-ae54-cae692f6096a@github.com>

On Thu, 31 Oct 2024 00:52:02 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:
> 
>> 187: 
>> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
>> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));
> 
> If these accesses need to be atomic, could you add a comment explaining why?

It is read concurrently by GC threads. Added comment.

> src/hotspot/share/runtime/deoptimization.cpp line 125:
> 
>> 123: 
>> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
>> 125:   if (!nm->can_be_deoptimized()) {
> 
> Is this a performance optimization?

No, this might be a leftover. When working on the change for Object.wait I was looking at the deopt code and thought this check was missing. It seems most callers already filter this case except WB_DeoptimizeMethod.

> src/hotspot/share/runtime/objectMonitor.cpp line 1612:
> 
>> 1610: 
>> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
>> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
> I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

The virtual thread is inside the thaw call here which is a leaf VM method, so there is no anchor. It is still in the mount transition before thawing frames. The top frame is Continuation.enterSpecial so that's what we set the anchor to.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:
> 
>> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
>> 43:   int64_t tid = thread->lock_id();
>> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Should the "3" be a named constant with a comment?

Yes, changed to use ThreadIdentifier::initial().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824792648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793200
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824791832
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793737

From pchilanomate at openjdk.org  Thu Oct 31 16:38:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
Message-ID: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>

On Thu, 31 Oct 2024 02:26:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
>> 
>>> 205: }
>>> 206: 
>>> 207: inline bool ObjectMonitor::has_successor() {
>> 
>> Why are _succ accesses atomic here when previously they were not?
>
> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

> Why are _succ accesses atomic here when previously they were not?
>
They should had always been atomic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794270

From pchilanomate at openjdk.org  Thu Oct 31 16:38:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 16:38:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <S8Ue5RVoGMMKyV7GW8zHn_nEvBb8xJzg40DVihS4q3U=.548f6940-e44c-44a8-9f2a-3f11b9c80c7a@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.9c6e9bbf-dd62-4fb8-a0cc-231e1ad95db9@github.com>
 <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.46b6b31e-71e9-4eff-bb1b-86787403c150@github.com>
Message-ID: <jY7WaK5NmmdDNXECTw7ByGpZ-QFceabiNhX5fucWL_E=.5854a481-b975-43d8-b49b-8c4f41a816cc@github.com>

On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.
>
>> Why are _succ accesses atomic here when previously they were not?
>>
> They should had always been atomic.

> But I agree it seems odd when direct accesses to _succ in the main cpp file are not atomic.
>
There was only one remaining direct access in debugging function `print_debug_style_on` which I fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794795

From duke at openjdk.org  Thu Oct 31 16:51:37 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 31 Oct 2024 16:51:37 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <1Xim6wW0FyJR3prCti1N3p9rwnL9-I67L947q4i7100=.3fe0d041-fefd-498d-a359-adf4d30d32e9@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
 <7EREZErHKW77dnrPaT8vK_gO12fvHfCmwkqQ140xfvQ=.f5c865d7-3ef4-4c7b-9785-3be7ba4dc9e0@github.com>
 <FgARKkGS_MVCdZtB8XF6xniRb7QR_erGAHjrb31M9PA=.8a9fe78e-2357-4c87-af44-69e42d64c110@github.com>
 <1Xim6wW0FyJR3prCti1N3p9rwnL9-I67L947q4i7100=.3fe0d041-fefd-498d-a359-adf4d30d32e9@github.com>
Message-ID: <WogSPywDVXx_qCXyK84EQrYIlW7Q6g3HAif1zYyQnWQ=.8eabfbe4-c7d8-4a63-b1fd-f5f1c82b6053@github.com>

On Thu, 31 Oct 2024 12:34:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> I had to analyze this again, to understand why we need this locking, since my mind slips.
>>> 
>>> I updated my findings in https://bugs.openjdk.org/browse/JDK-8325890 . Please see details there.
>>> 
>>> But I don't think the current locking makes much sense, tbh (even before this patch). Or I don't get it.
>>> 
>>> We have three counters in play here: A) the `malloc[mtChunk]` malloc counter for the mtChunk tag B) the global malloc counter C) the `arena[xxx]` arena counter for the mtXXX tag the arena is tagged with
>>> 
>>> Upon arena growth, we incremement all four. In two steps - first (A) and (B) under os::malloc, then (C) in the arena code.
>>> 
>>> Upon arena death, we may delete the chunk, in which case we adjust all three counters as well.
>>> 
>>> But since we don't want (B) to include arena sizes, we have several places where we lazily adjust (B) and (A) from the sum of all arena counters (see JBS issue). These adjustments must be synchronized with arena allocations. But we don't do this. The lock does not include (C). For that, the lock would have to be at a different place, inside arena code. We only lock around (A) and (B).
>>> 
>>> I am not sure what the point of this whole thing is. I am also not convinced that it always works correctly. This whole "updating counters lazily" business makes the code brittle.
>>> 
>>> Also, the current locking does not guarantee correctness anyway. There are several places in the coding where we calculate e.g. the sum of all mallocs, but malloc counters are modified (rightly so) out of lock protection.
>>> 
>>> To make matters even more complex, we have not two locks here but three:
>>> 
>>>     * ThreadCritical
>>> 
>>>     * the new `NmtVirtualMemory_lock`
>>> 
>>>     * we also have the `NMTQuery_lock`, which guards NMT reports from jcmd exclusively
>>> 
>>> 
>>> Not sure what the point of the latter even is. It certainly does not prevent us from getting reports while underlying data structures are being changed, unless I am overlooking something.
>>> 
>>> It would be very nice if someone other than me could analyze this.
>> 
>> If this is so brittle and complex, then I wonder what you even get out of us doing the `ThreadCritical` trick. In other words, if we just removed it, would anyone notice and be able to discern what's occurred? Open question, I might do that change and run the tests on it.
>
>> If this is so brittle and complex, then I wonder what you even get out of us doing the ThreadCritical trick. In other words, if we just removed it, would anyone notice and be able to discern what's occurred? Open question, I might do that change and run the tests on it.
> 
> @jdksjolen good question. I am not sure who introduced that, may have been Afshin as a fix for some NMT test.

Hi @tstuefe,

> But since we don't want (B) to include arena sizes, we have several places where we lazily adjust (B) and (A) from the sum of all arena counters (see JBS issue). These adjustments must be synchronized with arena allocations. But we don't do this. The lock does not include (C). For that, the lock would have to be at a different place, inside arena code

Yes, updating all three counters (A/B/C) is not atomic when [growing](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/arena.cpp#L294-L308) an arena or when [destroying](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/arena.cpp#L240) an arena. I think the `ThreadCritical`, that's meant to keep the accounting in sync, needs to be further up the stack when destroying arenas. What's strange is that there's no `ThreadCritical` protecting the growing operation at all. Why was there an attempt to only protect the freeing?  


I think this is also confusing because its not consistent whether we count arena sizes as part of malloc. In the NMT report total, arena is counted as malloc. But in the reported individual categories, arena is disjunct from malloc. 

The solution you mentioned in https://bugs.openjdk.org/browse/JDK-8325890 seems like it would solve this consistency problem while also avoiding the double counting problem with mtChunk.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2450355713

From duke at openjdk.org  Thu Oct 31 18:08:41 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 31 Oct 2024 18:08:41 GMT
Subject: RFR: 8304824: NMT should not use ThreadCritical [v9]
In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
References: <QoQzelas5AG8j5h-Qvs6fVmq8gk_wQyTq-ie_bprERg=.acd1e356-029b-42d5-8ddc-a24c58ee68cc@github.com>
 <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com>
Message-ID: <l48mioT27cXXI0HMkzTc-ouM71E07k4U88Hk9uPjv8E=.ce03a51a-d4ea-442c-9b4b-94336c342542@github.com>

On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> ### Summary
>> This PR just replaces `ThreadCritical` with a lock specific to NMT.  `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init.  There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests)  don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. 
>> 
>> Testing:
>> - hotspot_nmt
>> - gtest:VirtualSpace
>> - tier1
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add a comment explaining lock rank
>  - remove unnecessary dropping of tracking level

The easiest action to take would be to remove the `ThreadCritical` that attempts to keep NMT accounting in-sync in arena.cpp. It doesn't actually cover all cases, so we might as well not bother locking at all for slightly better performance and reduce the risk of bad lock ordering.

The next best solution would be to make arena size a subset of malloc size, and make mtChunk only responsible for free chunks not yet associated with other NMT categories. Then there would be no need for special adjustments when reporting, and thus no need for the special `ThreadCritical` locking here. And when calculating total sizes, we can simplify the calculation to summing up all "malloc" in MemoryCounter. No need to make a distinction between when it is/isn't appropriate to add on arena sizes. This would be a breaking change since it changes the meaning of arena, malloc, and mtChunk.  

The third and highest effort solution would be to remove the chunk pooling altogether as suggested in https://bugs.openjdk.org/browse/JDK-8325890. This shares the benefits of solution 2, but also requires performance testing and has consequences that extend beyond NMT. 


>Also, the current locking does not guarantee correctness anyway. There are several places in the coding where we calculate e.g. the sum of all mallocs, but malloc counters are modified (rightly so) out of lock protection.

Yes, still none of the three above solutions solve this.  Even with solution 2 or 3 it would be possible to update the arena sizes for each category concurrently with reporting (unless we introduce new locking).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20852#issuecomment-2450515494

From duke at openjdk.org  Thu Oct 31 18:43:32 2024
From: duke at openjdk.org (duke)
Date: Thu, 31 Oct 2024 18:43:32 GMT
Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have
 wrong behavior when pid == ns_pid [v3]
In-Reply-To: <V78g6WyyzPCDZyljQruRTCErpgGUY33N-fiGs4sc0g0=.0b663206-a5cd-4753-8de4-989e1935f51f@github.com>
References: <o1xuNReh58K-RmBQGtUKdvMkwQoI-GVnNfr94EyZfJ8=.0a19b1e5-29ab-459a-b212-a473b09512f8@github.com>
 <V78g6WyyzPCDZyljQruRTCErpgGUY33N-fiGs4sc0g0=.0b663206-a5cd-4753-8de4-989e1935f51f@github.com>
Message-ID: <YvyeGkkUDb604MMquwFAJw84oC4yttqYgdxl5r0BNBE=.d0949be1-bb19-4769-993c-b3a3d835b6a9@github.com>

On Wed, 30 Oct 2024 17:20:49 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the implementation I originally provided does not in fact solve the issue!
>> 
>> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
>> 
>> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
>> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
>> 
>> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
>> 
>> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
>> 
>> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
>> 
>> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
>> 
>> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
>> 
>> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
>> 
>> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
>> 
>> therefore an "attacher" has two choices when attempting to attach:
>> 
>> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>>   - this works with both peers and descendants
>> 
>> - use /tmp
>>   - this only works if the "attacher" and "attachee" share a /tmp in common
>> 
>> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
>> 
>> I...
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8342449: fixed missing param in throws msg and renamed local var

@larry-cable 
Your change (at version 2e89bd530581030380a1822117161d894db61912) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2450584300

From cjplummer at openjdk.org  Thu Oct 31 19:10:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 31 Oct 2024 19:10:31 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
Message-ID: <e2KFFg9X0NbkZZxfCS_ZfoayaDU71HIBtuV0Ir-guW4=.66d3fc28-02e9-4658-b100-313cedd10ad9@github.com>

On Thu, 31 Oct 2024 07:18: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 incrementally with one additional commit since the last revision:
> 
>   Remove global memHandle, would've liked to keep it as a comment :(

The JDI and JDWP changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2408881262

From cjplummer at openjdk.org  Thu Oct 31 19:10:31 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 31 Oct 2024 19:10:31 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
 <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
 <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>
Message-ID: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>

On Thu, 31 Oct 2024 07:13:56 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem
> 
> I'll also start looking into this in the meantime, unless you explicitly want me not to do so

Feel free to if you'd like to. Personally I don't consider it to be that important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2450630093

From dlong at openjdk.org  Thu Oct 31 19:11:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:11:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <p0EL5sSXDA_lCNzjlh-_wA7MtNlF7wyKjQdldfSaogY=.6a8b3970-8fdf-45dd-bff6-bdb6fbd2ab75@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/vframe.cpp line 289:

> 287:       current >= f.interpreter_frame_monitor_end();
> 288:       current = f.previous_monitor_in_interpreter_frame(current)) {
> 289:       oop owner = !heap_frame ? current->obj() : StackValue::create_stack_value_from_oop_location(stack_chunk(), (void*)current->obj_adr())->get_obj()();

It looks like we don't really need the StackValue.  We might want to make it possible to call oop_from_oop_location() directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757

From cjplummer at openjdk.org  Thu Oct 31 19:13:29 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 31 Oct 2024 19:13:29 GMT
Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do
 not cause test failure
In-Reply-To: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com>
References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com>
Message-ID: <qpvGQTCBiGSIasess3-_A5KZ0gux6mFrz0R9YhwQDp4=.f2a7e365-454c-4a1b-970b-7b369cd40810@github.com>

On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Test update: fail when it hits an Exception.
> 
> This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this.
> I am working on http, so we may revisit these tests in future to change their list of protocols.
> 
> For now, I'd like to simply make this test fail if any of the protocols it tests have failures.
> Fix a few typos while we are here.

test/jdk/javax/management/remote/mandatory/connection/DeadLockTest.java line 54:

> 52:                 test(protocols[i]);
> 53:             } catch (Exception e) {
> 54:                 fail = true; // any one protocol failure, fails the test

Suggestion:

                fail = true; // any one protocol failure fails the test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1825048045

From dlong at openjdk.org  Thu Oct 31 19:16:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:16:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/runtime/vframe.inline.hpp line 130:

> 128:       // Waited event after target vthread was preempted. Since all continuation frames
> 129:       // are freezed we get the top frame from the stackChunk instead.
> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);

What happens if we don't do this?  That might help explain why we are doing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976

From dlong at openjdk.org  Thu Oct 31 19:20:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 19:20:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <vVmCo-n8F4TL2Si5e7S5oTlZf3BCOYzVwyvQgC42ewU=.46d8f3eb-9721-46f2-98f8-a1e6dcd22df0@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:         }

Please explain why it is safe to remvoe the above code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769

From szaldana at openjdk.org  Thu Oct 31 19:26:30 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 31 Oct 2024 19:26:30 GMT
Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2]
In-Reply-To: <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
 <VZjH1T-025qHpNUGt8JlEtWO6ZNM3fToS2sWShdhWos=.915df9c9-37bb-4b05-bec8-f982448c60bf@github.com>
Message-ID: <rIrwsqQBulhxprxu1PmMg9JvsZEFzBUC_BsRU0hDa3w=.767f1965-2b3a-4a80-88e8-5933648cec94@github.com>

On Tue, 10 Sep 2024 15:42:57 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
>
> Sonia Zaldana Calles 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 two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8204681
>  - 8204681: Option to include timestamp in hprof filename

Hi folks, 

Thanks for your comments. I spent some time today prototyping how to reuse UL tag logic. Like @kevinjwalls mentioned, it becomes a bit tricky when the identifiers are more than one letter. Especially as it might lead to some unintended consequences. For example, a user can specify the file name `my%tinstance` and end up with a thread id (`ti` per UL tags) versus an intended timestamp. 

I didn?t want to spend too much time on making the 2-letter identifiers work but I made some small changes to use UL tags in general. Looks like [this](https://github.com/SoniaZaldana/jdk/commit/36cdef1a598761e5310da4e30c39e818f2ff1230).

Note the timestamp is diplayed in the following format: `2024-10-31T15:14:39.344-0400`

As far as the scope of this PR, I'm okay to implement it using UL tags (one or two letters) if we feel that will serve argument expansion in the long term. However, I still have the question about backwards compatibility. Would reviewers be receptive to changing `Arguments::copy_expand_pid` to `Arguments::copy_expand_arguments` and propagate that across all places where `Arguments::copy_expand_pid` as originally proposed or is there another preferred approach? 

Thanks for taking a look! 

Sonia

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2450656058

From jlu at openjdk.org  Thu Oct 31 19:58:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Oct 2024 19:58:36 GMT
Subject: RFR: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent
Message-ID: <OVI-gZH4CPI5yDvSu5FCEOFa9Zotku4d_gRe_N04hHs=.bd635cf3-a20d-496c-8921-62a128ff26e5@github.com>

Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_.

This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21813/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21813&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341796
  Stats: 26 lines in 5 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/21813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21813/head:pull/21813

PR: https://git.openjdk.org/jdk/pull/21813

From pchilanomate at openjdk.org  Thu Oct 31 20:02:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 20:02:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v24]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <V6WytPJ_bdxusndeknCz0Rh4NyaZhG1YlOWKCV9A_Es=.f72d1ae9-7d24-4217-a5d1-3c7f86a97dc1@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:

 - Remove redundant assert in ObjectMonitor::VThreadEpilog
 - Comment in FreezeBase::recurse_freeze + renames in continuation.hpp
 - Explicitly pass tmp register to inc/dec_held_monitor_count + use static const in clobber_nonvolatile_registers
 - Use frame::sender_sp_offset in continuationFreezeThaw_riscv.inline.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/9f086c52..aa263f56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=22-23

  Stats: 43 lines in 16 files changed: 2 ins; 3 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From dlong at openjdk.org  Thu Oct 31 20:02:49 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 20:02:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:

> 55:     static {
> 56:         try {
> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);

Why is this needed?  A comment would help.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245

From jlu at openjdk.org  Thu Oct 31 20:14:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Oct 2024 20:14:43 GMT
Subject: RFR: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent [v2]
In-Reply-To: <OVI-gZH4CPI5yDvSu5FCEOFa9Zotku4d_gRe_N04hHs=.bd635cf3-a20d-496c-8921-62a128ff26e5@github.com>
References: <OVI-gZH4CPI5yDvSu5FCEOFa9Zotku4d_gRe_N04hHs=.bd635cf3-a20d-496c-8921-62a128ff26e5@github.com>
Message-ID: <E-Pk4DtHIUrSoWwjXOkHe2jnljNw8tbCjcgBeXJPf4g=.475a25a6-08b9-4853-a170-cc949843d002@github.com>

> Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_.
> 
> This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  for consistency, include the comments as well

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21813/files
  - new: https://git.openjdk.org/jdk/pull/21813/files/f6cd840f..63e67af7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21813&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21813&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21813.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21813/head:pull/21813

PR: https://git.openjdk.org/jdk/pull/21813

From jlu at openjdk.org  Thu Oct 31 20:18:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 31 Oct 2024 20:18:48 GMT
Subject: RFR: 8341798: Fix ExceptionOccurred in jdk.jdwp.agent
Message-ID: <Ugidm9MYxKiCKI0RNUM7-YvyVg9MoQPQBi4YiKZphm0=.f09e648e-ed5c-4577-8570-9da2cfccc394@github.com>

Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_.

This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/21814/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21814&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341798
  Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/21814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21814/head:pull/21814

PR: https://git.openjdk.org/jdk/pull/21814

From pchilanomate at openjdk.org  Thu Oct 31 20:20:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 20:20:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
Message-ID: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>

On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:
> 
>> 943: 
>> 944:   void inc_held_monitor_count();
>> 945:   void dec_held_monitor_count();
> 
> I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 
> 
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:
> 
>> 738: void MacroAssembler::clobber_nonvolatile_registers() {
>> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
>> 740:   Register regs[] = {
> 
> Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
> Suggestion:
> 
>   static const Register regs[] = {

Added.

> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
> 
>> 271:         ? frame_sp + fsize - frame::sender_sp_offset
>> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
>> 273:         : *(intptr_t**)(hf.sp() - 2);
> 
> Suggestion:
> 
>         : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

Changed.

> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:
> 
>> 791: 
>> 792:   void inc_held_monitor_count(Register tmp = t0);
>> 793:   void dec_held_monitor_count(Register tmp = t0);
> 
> I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/share/runtime/continuation.cpp line 125:
> 
>> 123: };
>> 124: 
>> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt_for_jvmti.

> src/hotspot/share/runtime/continuation.cpp line 135:
> 
>> 133: #endif // INCLUDE_JVMTI
>> 134: 
>> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt, which I think it reads even better.

> src/hotspot/share/runtime/continuation.hpp line 66:
> 
>> 64: 
>> 65:   enum preempt_kind {
>> 66:     freeze_on_monitorenter = 1,
> 
> Is there a reason why the first enumerator doesn't start at zero?

There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:
> 
>> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
>> 888:   } else {
>> 889:     return freeze_pinned_native;
> 
> Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

We just found a frame that can't be freezed, most likely the call_stub or upcall_stub which indicate there are further natives frames up the stack. I added a comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1193:
> 
>> 1191:   }
>> 1192: 
>> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");
> 
> In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

The `guarantee` tries to mimic the one here: https://github.com/openjdk/jdk/blob/ae82cc1ba101f6c566278f79a2e94bd1d1dd9efe/src/hotspot/share/runtime/objectMonitor.cpp#L1613
The assert at the epilogue is probably redundant. Also in `UnlinkAfterAcquire`, the else branch already asserts `ObjectWaiter::TS_CXQ`. I removed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101744
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825108078
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825100526
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101246
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107036
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825102359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825103008
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825106368

From dlong at openjdk.org  Thu Oct 31 20:20:58 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 31 Oct 2024 20:20:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
Message-ID: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>

On Wed, 30 Oct 2024 22:44:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in comments

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:

> 106:         processDeregisterQueue();
> 107: 
> 108:         if (Thread.currentThread().isVirtual()) {

It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

test/hotspot/gtest/nmt/test_vmatree.cpp line 34:

> 32: 
> 33: using Tree = VMATree;
> 34: using TNode = Tree::TreapNode;

Why is this needed?

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:

> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos

I'm guessing these changes have something to do with JDK-8279653?

test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:

> 71: /* ========================================================================== */
> 72: 
> 73: static int prepare(JNIEnv* jni) {

Is this a bug fix?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825109698
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107638

From alanb at openjdk.org  Thu Oct 31 20:20:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:20:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
Message-ID: <RtT7q4CD6pe5qYxQQCHybX2wyJ4UQONkL6OSDjiBAVo=.e6bfc819-297a-41fb-bf72-e33f4e6434e6@github.com>

On Thu, 31 Oct 2024 20:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:
> 
>> 106:         processDeregisterQueue();
>> 107: 
>> 108:         if (Thread.currentThread().isVirtual()) {
> 
> It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

When executed on a platform thread is will block in epoll_wait or kqueue so it has to handle EINTR. It doesn't block in sys call when executed in a virtual thread. So very different implementations.

> test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:
> 
>> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
>> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
>> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos
> 
> I'm guessing these changes have something to do with JDK-8279653?

It should have been added when Thread.sleep was changed but we got lucky.

> test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:
> 
>> 71: /* ========================================================================== */
>> 72: 
>> 73: static int prepare(JNIEnv* jni) {
> 
> Is this a bug fix?

Testing ran into a couple of bugs in JVMTI tests. One of was tests that was stashing the JNIEnv into a static.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254

From alanb at openjdk.org  Thu Oct 31 20:26:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:26:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <W4e8JgE9qTboFhdEKQIBAv-JWVA9uO_w5h3DLkkpkgo=.b5fe42f3-9992-417b-b7a6-c3672aeda600@github.com>
Message-ID: <7hUuYlCwm3busYFnC5Z0Iq7bv8204h26-nAfOBnIStU=.4e387823-c30e-45a4-889c-fbe9ffffca30@github.com>

On Thu, 31 Oct 2024 20:12:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> test/hotspot/gtest/nmt/test_vmatree.cpp line 34:
> 
>> 32: 
>> 33: using Tree = VMATree;
>> 34: using TNode = Tree::TreapNode;
> 
> Why is this needed?

We had to rename the alias to avoid a compiling with the Node in compile.hpp. Just lucky not to run into this in main-line. I think Johan had planned to change this in main line but it may have got forgotten.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520

From alanb at openjdk.org  Thu Oct 31 20:30:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 31 Oct 2024 20:30:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>
Message-ID: <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@github.com>

On Thu, 31 Oct 2024 19:59:00 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:
> 
>> 55:     static {
>> 56:         try {
>> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
> 
> Why is this needed?  A comment would help.

That's probably a good idea.  It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591

From kevinw at openjdk.org  Thu Oct 31 20:58:28 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 31 Oct 2024 20:58:28 GMT
Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do
 not cause test failure
In-Reply-To: <qpvGQTCBiGSIasess3-_A5KZ0gux6mFrz0R9YhwQDp4=.f2a7e365-454c-4a1b-970b-7b369cd40810@github.com>
References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com>
 <qpvGQTCBiGSIasess3-_A5KZ0gux6mFrz0R9YhwQDp4=.f2a7e365-454c-4a1b-970b-7b369cd40810@github.com>
Message-ID: <zOVNRQbwe5DsxaQWs-BRaAsCeEGnDxqYXyvjqgIsMiA=.6f50b585-ce60-493a-8aef-f2e65895da12@github.com>

On Thu, 31 Oct 2024 19:10:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Test update: fail when it hits an Exception.
>> 
>> This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this.
>> I am working on http, so we may revisit these tests in future to change their list of protocols.
>> 
>> For now, I'd like to simply make this test fail if any of the protocols it tests have failures.
>> Fix a few typos while we are here.
>
> test/jdk/javax/management/remote/mandatory/connection/DeadLockTest.java line 54:
> 
>> 52:                 test(protocols[i]);
>> 53:             } catch (Exception e) {
>> 54:                 fail = true; // any one protocol failure, fails the test
> 
> Suggestion:
> 
>                 fail = true; // any one protocol failure fails the test

I actually think it's more readable with the comma.
If there is (one protocol failure), then that (fails the test).
Without the comma, "failure fails" runs together, but the failure did not fail, it was a perfectly good failure.  Pause for breath. What do we do now?  Well, experiencing that kind of problem, fails the test.

Extended discussions on language style, from the test that brought you "listner" and "should no block". 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1825154594

From fbredberg at openjdk.org  Thu Oct 31 21:14:51 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 31 Oct 2024 21:14:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
Message-ID: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>

On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.hpp line 66:
>> 
>>> 64: 
>>> 65:   enum preempt_kind {
>>> 66:     freeze_on_monitorenter = 1,
>> 
>> Is there a reason why the first enumerator doesn't start at zero?
>
> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825168519

From sgehwolf at openjdk.org  Thu Oct 31 21:19:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 31 Oct 2024 21:19:45 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v12]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <grQQFetNMizjqv5thn0aXPMChL3dO6ZfiIIUUOP3cUI=.aa7cbe0e-1504-46e0-a659-bc2b9a94d630@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 37 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
 - 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
 - Merge branch 'jdk-8322420_cgroup_hierarchy_walk_init' into jdk-8336881-metrics-systemd-slice
 - ... and 27 more: https://git.openjdk.org/jdk/compare/c40bb762...8022e864

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=11
  Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 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 pchilanomate at openjdk.org  Thu Oct 31 21:50:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:50:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - add comment to ThreadService::find_deadlocks_at_safepoint
 - Remove assignments in preempt_kind enum

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/aa263f56..e5a9ce2a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=23-24

  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Thu Oct 31 21:50:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:50:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.b620d486-c75f-40f3-b11b-50396c1f75b9@github.com>
Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.c2ffa35e-fe62-4f3e-a3ae-b01c19a924b7@github.com>

On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.
>
> Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

Yes, I missed to include it in the previous changes. I actually removed the assignment altogether since there is no need to rely on particular values (although it will start at zero by default).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825202651

From pchilanomate at openjdk.org  Thu Oct 31 21:54:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 31 Oct 2024 21:54:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <5Q-i6W9AXq3oQ__tUwwX_eE5NMiDczNdpuQv_oSHzuk=.687da571-23db-48cd-b82d-769f4c4c7453@github.com>
Message-ID: <tq9aHsQgDVjbvosLzR6tYM3Gs4-sblUlfXeLdnw_WuM=.b5a8125f-85bd-4017-ac2a-2bbdffc39153@github.com>

On Thu, 31 Oct 2024 19:13:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos in comments
>
> src/hotspot/share/runtime/vframe.inline.hpp line 130:
> 
>> 128:       // Waited event after target vthread was preempted. Since all continuation frames
>> 129:       // are freezed we get the top frame from the stackChunk instead.
>> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);
> 
> What happens if we don't do this?  That might help explain why we are doing this.

We would walk the carrier thread frames instead of the vthread ones.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:         }
> 
> Please explain why it is safe to remvoe the above code.

Yes, I should have added a comment here. The previous code assumed that if the monitor had an owner but it was not findable it meant the previous currentThread will be blocked permanently and so we recorded this as a deadlock. With these changes, the owner could be not findable because it is an unmounted vthread. There is currently no fast way to determine if that's the case so we never record this as a deadlock. Now, unless there is a bug in the VM, or a thread exits without releasing monitors acquired through JNI, unfindable owner should imply an unmounted vthread. I added a comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260

From cjplummer at openjdk.org  Thu Oct 31 22:00:33 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 31 Oct 2024 22:00:33 GMT
Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do
 not cause test failure
In-Reply-To: <zOVNRQbwe5DsxaQWs-BRaAsCeEGnDxqYXyvjqgIsMiA=.6f50b585-ce60-493a-8aef-f2e65895da12@github.com>
References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com>
 <qpvGQTCBiGSIasess3-_A5KZ0gux6mFrz0R9YhwQDp4=.f2a7e365-454c-4a1b-970b-7b369cd40810@github.com>
 <zOVNRQbwe5DsxaQWs-BRaAsCeEGnDxqYXyvjqgIsMiA=.6f50b585-ce60-493a-8aef-f2e65895da12@github.com>
Message-ID: <07kSV5FDDKBnyWvsM8qELMdZ7llvUV_l_HjS4sWgT6k=.5bd99d2e-73b8-409a-a1d8-b09a69f23493@github.com>

On Thu, 31 Oct 2024 20:55:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/remote/mandatory/connection/DeadLockTest.java line 54:
>> 
>>> 52:                 test(protocols[i]);
>>> 53:             } catch (Exception e) {
>>> 54:                 fail = true; // any one protocol failure, fails the test
>> 
>> Suggestion:
>> 
>>                 fail = true; // any one protocol failure fails the test
>
> I actually think it's more readable with the comma.
> If there is (one protocol failure), then that (fails the test).
> Without the comma, "failure fails" runs together, but the failure did not fail, it was a perfectly good failure.  Pause for breath. What do we do now?  Well, experiencing that kind of problem, fails the test.
> 
> Extended discussions on language style, from the test that brought you "listner" and "should no block". 8-)

The best way to get to the right answer here is simplify to the subject and verb: "failure fails". You don't put a comma between the subject and the verb, unless is something more much complex like "a failure, for which there can be more than one, fails the test". I think the reason you feel it reads better with the comma is because of the repetition of "fail". Would you still want a comma if the sentence was "any one protocol error fails the test"? I assume no, but the sentence is structurally identical.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1825216696

From rengels at ix.netcom.com  Tue Oct 15 13:20:56 2024
From: rengels at ix.netcom.com (Robert Engels)
Date: Tue, 15 Oct 2024 13:20:56 -0000
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager
In-Reply-To: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@github.com>
References: <UeySvh7AQqeSsG8yAZRYFmWTuf83RoFP5lMQgxVOLt4=.a8119b9a-13ad-4079-a67a-7d930aa271df@github.com>
Message-ID: <BA73B8F4-E865-43C0-A2E4-A8FD3B1A23FF@ix.netcom.com>

Just read the JEP for this. Very poor decision in my part - maybe Java?s death knell. Going to make IDEs with plugins huge security risks. 

How hard is it to maintain 1000 one line pieces of code?

Someone commercial company is going to write an agent and essentially replicate all of these calls. 

Not sure what?s happening with the Java steering committee. 

> On Oct 15, 2024, at 8:04?AM, Chen Liang <liach at openjdk.org> wrote:
> 
> ?On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:
> 
>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR.
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...
> 
> @seanjmullan I think you can use many lines of command in one github comment, like
> 
> -------------
> 
> PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563

From rotanolexandr842 at gmail.com  Thu Oct 24 07:47:10 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 24 Oct 2024 07:47:10 -0000
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <oOizZPpgL6-B1EjylbMiRiLpq_PH0S5AOMxAxfAOQr0=.8f3d7234-54f2-465c-a354-a651f7528d14@github.com>
Message-ID: <CAL5bRt_FvQtBcE0Wjswe2rXs+08RM+ymrwjxfR831cJd_figZw@mail.gmail.com>

Hi. Just wanted to express my gratitude to everyone who has been working on
this and virtual threads as a whole. I am a big fan of this technology and
seeing largest issue go away makes me incredibly happy. Thanks for loom
team and everyone else who took part in this great innovation (instead of
turning each codebase into async/await painting competition :) )

On Thu, Oct 24, 2024, 10:06 Alan Bateman <alanb at openjdk.org> wrote:

> On Thu, 24 Oct 2024 02:42:35 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:
> >>
> >>   Minor fixes in inc/dec_held_monitor_count on aarch64 and riscv
> >
> > src/java.base/share/classes/java/lang/Thread.java line 655:
> >
> >> 653:      * early startup to generate the identifier for the primordial
> thread. The
> >> 654:      * counter is off-heap and shared with the VM to allow it
> assign thread
> >> 655:      * identifiers to non-Java threads.
> >
> > Why do non-JavaThreads need an identifier of this kind?
>
> JFR. We haven't changed anything there, just the initial tid.
>
> -------------
>
> PR Review Comment:
> https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20241024/c3953c3d/attachment.htm>